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FOREWORD 

This report documents in three volumes the work performed by TRW 
Electronics and Defense Sector, Redondo Beach, California, for 
George C. Marshall Space Flight Center (NASA/MSFC), Huntsville, Alabama, 
under contract NAS8-33198 (TRW Sales Number 34579). 

Volume 1, "Reference EPS Design," summarizes the work under Task 1, 
System Design and Technology Development; Volume 2, Autonomous Power Man- 
agement, summarizes the work under Task 2, Power Management Subsystem 
Development; and Volume 3, Test Facility Design, summarizes the work under 
Task 3, AMPS Test Facility. This final report is submitted in compliance 
with the contract statement of work and covers the entire period of per- 
formance from 1978 December 05 through 1982 March 31. 

These three tasks were structured to define, develop, and demonstrate 
technology for autonomous management of complex multi-hundred-ki lowatt 
electrical power subsystems for orbital spacecraft. Initially, a concep- 
tual design of a reference electrical power subsystem was developed frcm 
spacecraft level life cycle cost analyses of 1985-86 technology for soiar 
array, energy storage, power distribution, shuttle transportation, and 
orbital drag makeup propulsion (Volume 1). This reference electrical power 
subsystem was subsequently utilized to quantify the benefits of the power 
management approach and to demonstrate the power management subsystem 
concept (Volume 2). It is important to recognize that the resultant power 
management technology (strategies and hardware) has application to a broad 
spectrum of electrical power systems and is independent of power level, 
distribution voltage and form (ac or dc), payload type, spacecraft mission, 
and orbital parameters. 

This study was managed for TRW by Charles Sollo of the Electrical 
Power Systems Laboratory, and for NASA/MSFC by Jim Graves of the Power 
Branch. The principal contributors for this technical study task and 
preparation of this report volume include D. Kent Decker, Marshall D. 
Cannady, John E. Cassinelli, Bertrand F. Farber, Charles Lurie, Gerald W. 
Fleck, Jack W. Lepisto, Alan Messner, and Paul F. Ritterman. Their par- 
ticipation is gratefully acknowledged. 
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i. INTRODUCTION 

The growing size and coaiplexlty of spacecraft power systems coupled 
with limited space/ground communications necessitate Increasingly automated 
onboard control systems. Efforts to address this problem have focussed on 
relatively low level algorithmic control, such as solar array orientation 
and shunt regulation, resulting In Impressive improvements in both opera* 
tions cost and system performance. Higher levels of control are effected 
through ground-based monitoring and commanding. Voltage and current limit 
select1<^s are examples of this level of control. Further attempts at 
automating space power systems will Med to address control functions at 
this higher level and beyond. Substantial potential exists to automate 
routine operatiMS and maintenance functions and to aid In the diagnosis 
and recovery from system anc^lles. 

NASA and military applications for high poMr large space platforms 
and mannable space statl^y^s are presen>.ly being planned. Each satellite 
will provide an electrical power utility for a wide variety of missions and 
payloads over several decades of satellite life (30 years or more). As 
such, these satellites must provide operational flexibility and load 
adaptability in a cost-effective manner with the capability for evolu- 
tionary growth and performance upgrading as mission profiles change. These 
large, long-life spacecraft present new challenges from the standpoint of 
Increased system complexity, new maintenance strategies utilizing space 
shuttle resupply. Increased ground station operational burden, and surviva- 
bility with unattended operation. Autor(»nous power management has been 
proposed as a solution to these new challenges. 
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2. EXECUTIVE SUMHARY 

The concept of autonomous operation, as defined for this project, 
extends beyond the present day control strategies for safe haven and auto- 
mated operation. Safe haven operation provides for the shutdown of equip- 
ment up(xi an out -of -tolerance performance condition. A ground command Is 
required to reinitiate or override the shutdown condition. Automated 
operation takes the safe haven strategy one step further by switching to a 
redundant unit upon the out-of -tolerance operating condition. Equipment 
shutdown occurs (safe haven) If the redundant unit operates with an out-of- 
tolerance condition, and a ground command Is used at that time to reini- 
tiate operation. 

Autonomous operation extends beyond this automated operation control 
strategy by continuing to operate In a degraded mode with the best of the 
available units. Maximum usage of the remaining available power Is made by 
reducing or reallocating loads. A retrenchment to the safe haven mode 
occurs only upon extensive performance degradation causing loss of auton- 
omous control. Ground commands are then used as backup or for unforeseen 
failure modes. 

Implementation of autoncxnous operation can provide substantial 
benefits: 

a) Power availability is Increased. 

b) Critical conditions are minimized by the enhanced speed 
of recovery after fault Isolation. 

c) The power subsystem Is saf vhen out of communication 
with terrestrial control. 

d) The level and cost of operational support Is reduced. 

e) The quality of power service 1s Improved. 

In addition, the equipment providing autonomous operation may be 
further utilized to: 

a) Extend equipment life through automated load management 
strategies. 

b) Fully allc.'.e the available electrical power generation 
capacity. 
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c) Manage the consiimption rates of stored energy to enhance 
system performance, extend equipment or mission life, or 
maximize output poMer. 

The value of these benefits typically outweigh the cost and weight of 
the additional onboard computational equipment and sensors required to 
implement autwKxnous control. 

2.1 SCOPE 

The scope of this task is to develop the concept for an autonomously 
managed power system (AMPS) based wt the electrical power subsystem (EPS) 
reference design of Volume 1, to initiate the design and development of the 
essential components of the power management subsystem (PMS) portion of the 
autonomously managed power system, to initiate development of the associ- 
ated algorithms necessary to perform the required power subsystem moni- 
toring and control functions, and to idoitify the associated technology 
drivers. 

The primary functions of autonomous operation are to recognize a 
fault, isolate the fault quickly, and reconfigure the power subsystem to 
recover functional operation so that the satellite mission may continue. 
Implementation of these functions requires adequate sectionalization of 
critical equipment, alternate operational paths or modes, and/or redun- 
dancy. A set of managenent strategies (algorithms), that are preplanned, 
are required to define the operating options and decisions within the 
Inherent isolation and recovery limitations for the conceivable faults. 
Sensors (to acquire subsystem operational and state-of-health data), data 
and program storage, computational equipment, and subsystem control actu- 
ators (to implement reconfiguration decisions) are required to implement 
these functions. This study task addresses the configuration of PMS equip- 
ment to enhance autcxnatlon options and operational strategies. 

2.2 REQUIREMENTS 

The contractual statement of work outlines a four-step program to 
define a power management subsystem (PMS) for development and demonstration 
of autcmomous operation of multi -hundred-kilowatt electrical power systems 
for spacecraft: 

a) Develop an autonomous power management concept compatible 
with the 250 kilowatt electrical power system definition. 
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b) Assess the technology status to define component and 
process deficiencies and the technology drivers for a 
1985-86 technology readiness and a 1988 initial 
operational capability. 

c) Identify the power management strategies control laws, 
and algorithms required for automated control including 
definition of monitors and sensors, control switches and 
effectors, and computational capacity and speed. 

d) Initiate breadboard development hardware and software 
development to demonstrate the power management concepts, 
and ultimately integrate this PMS with a multi-channel, 
high-voltage, high-power test facility representative of 
a portion of a 250 kilowatt power system. 

Management requirements and functions were subsequently defined to 
identify the operational roles of a PMS. These requirements and their 
related functions were grouped into a matrix (Table 2-1) according to 
potential geographic management centers (power sources, load centers, and 
integrated electrical subsystan) and by perceived operational categories 
(mission operation, maintenance, and degradation/fault accommodation). 

From this matrix, the management algorithm list and the topology and 
hierarchy of the distribution of power management control were developed. 

2.3 ALGORITHM DEVELOPMENT 

The functions that are performed within the EPS must be transformed 
into algoritimis during the development of autonomous power subsystem man- 
agement. Algorithms are the defined processes, rules, or procedures that 
are assigned to the functions to assure the realization of a desired output 
from given input conditions. Usually, algorithms are a sequence of formu- 
las and/or algebraic logical steps that calculate a particular result or 
determine a given task. 

The major algorithms identified for an autonomously managed power 
subsystem are listed in Table 2-2. These algorithms are derived directly 
from the functions that are performed in the EPS, as shown in Table 2-1. 
These algorithms are grouped into the three main categories of power source 
management, load center management, and EPS management. 


Table 2-1. Management Requirements and Functions 
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Table 2-2. List of Algorithms 


Power Source Management 
• Battery Charge Control 
e Battery State of Health 

- Reconditioning 

- Treid Projection 
§ Solar Array Status 

- SASU Switch Status 

EPS Management 
e Energy Planning and Allocation 

- Solar Array Power Reallocation 
t Load Bus Assignments 

• Power Subsystem State of Health 

- Replacement Scheduling 

- Controller Anomally 


Load Center Hanagement 
e Command Processing 

- Circuit Breaker Programming 
t Switch and Load Bus Monitoring 

- Fault Definition 


In general, a first iteration of each algorithm was developed to the 
functional definition as described in Section 5. Portions of the load bus 
assignments, command processing, and switch and load bus monitoring algo- 
rithms were developed through the implementation and testing stages. These 
algorithms were developed to verify operation of the load center controller 
and EPS controller (EPSC) that were developed during this phase of the pro- 
gram. These algoritNns were implemented in FORTH, a high-level programming 
language that was determined to be best suited for the AMPS application. 

In additiwt to the functional algorithms listed in Table 2-2, each 
controller requires an executive algorithm. The executive algorithm man- 
ages the overall operation of the controller. Functions provided by the 
executive algorithm are process scheduling, management of common data 
buffers, timer services, and data bus adapter interfacing. 
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2.4 POWER MANAGEMENT SUBSYSTEM DESCRIPTION 

The power management subsystem (PMS) monitors and controls the elec- 
trical power subsystem (EPS) from the power source to the loads so that the 
monitoring, processing and decision making, command, and memor 7 functions 
can be efficiently and predictably performed. The PMS consists of power 
source controllers (PSCs), load center controllers, (LCCs), electrical 
power subsystem controller (EPSC), the data bus between the controllers, 
and the Interfacing input/ output (I/O) circuitry between each controller 
and Its respective sensors and effectors (typically switch gear^. 

A decentralized data processing approach was selected for the PMS 
based on the EPS algoritNns that are to be performed and the control hier- 
archy trade studies and analyses. The PMS Is a decentral ued processing 
system frtnn the standpoint that the PSCs, LCCs, and I/O circuitry are dis- 
tributed throughout the spacecraft at various functional centers. The dis- 
tributed processing concept for an autonomously managed EPS is shown in 
Figure 2-1. The power system controller and the redundant unit are located 
In the spacecraft control center where power subsystem Information Is dis- 
played for onboard personnel and Is also available for further processing 
to ground through telemetry and conmand subsystems. Power system commands 
are also received through these same channels and are routed to the func- 
tional centers via the data bus. Power source controllers are located at 
power generatlw centers where solar array power Is Integrated with energy 
storage device power to form the main power buses for the spacecraft. The 
main buses are then routed to the various spacecraft load centers where the 
LCCs are located. The LCCs provide power control commands for load bus and 
payload operations and monitor the Implementing switch gear operational 
status. Distribution voltages and currents are monitored and power levels 
calculated. 

Three types of microprocessor-based controllers are defined In the 
selected PMS concept: EPSC, PSC, and LCC. The primary function of each 
controller Is to generate logical control decisions for the operation of 
the EPS and to manipulate sensor and other Input data. To accomplish this, 
logical processing and data storage functions are required. The microproc- 
essor and memory elements of each controller Implanent these functions. 
These elements also provide the mechanization to program the algorithms 


20 



21 


Figure 2-1. Distributed Processing for an Autonomously Managed 
Electrical Power System 
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that govern the control operations. The remaining major elements In each 
controller are I/O oriented and dependent upon the execution and 1mp1e- 
mentatlm requirements of the control functions assigned to each 
controller. 

Each controller may communicate Mith the other controllers over a 
common data bus. A bus Interface adapter (BIA) In each controller 
Implements this communication path by formatting the output data Into an 
appropriate message structure (rate, format, time slot). The BIA also 
recognizes a proper input mssage structure and decodes this message Into 
data/comnand format. The BIA consists of four sections: bus I/O circuits, 
bus protocol logic, data buffers, and direct metiwry access I/O logic. 

Additional elements are Included In each controller to provide periph- 
eral but practical features such as poner-on reset, timing checks to escape 
from a nondefinitive or excessively lengthy processing routine, and Inter- 
rupt procedures to prioritize processing routines, A digital I/O port Is 
provided each controller for a serial data Interface to provide for 
human Interactions with the systmn. These peripheral devices, such as 
printers and video /keyboard terminals, may be connected to the system dur- 
ing development, testing, and demonstration. 

The I/O circuitry consists of sensors, actuators, and their signal 
processing circuitry. Monitoring functions are Implemented by the use of 
sensors. Sensors measure various system parameters and generally transform 
these signals Into analogs that are usable by the electronic signal proc- 
essing circuitry. The outputs from the sensors are analog signals that are 
proportional to the Input parameters or status devices such as relay con- 
tacts that Indicate change In status. Typically, analog sensors are volt- 
age, current, pressure, and temperature transducers. 

The signal processing circuitry gathers data from the sensors and 
processes this data so that It can be used by the PSC or LCCs. The signal 
processing circuitry Is, therefore, performing a portion of the processing 
and decision function. A second responsibility of the signal processing 
circuitry Is to process commands from the controllers and route them to the 
appropriate actuators. Specific functions of the signal processing circui- 
try are multiplexing of sensor channels, analog-to-digital conversion, 
digital -to-analog conversion, encoding and decoding, and logic functions. 
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The I/O circuitry also provides the Interface with onboard personnel 
for the monitoring and control of the power system. Power system condi- 
tions are displayed by means of status Indicators and Information Is pro- 
vided through readout devices such as video displays. Commands are Issued 
through Input terminals such as keyboards. 

2.5 HARDWARE DEVELOPMENT 

An EPSC and a LCC were developed during this phase of the program. 

Each controller consists of a microprocessor, memory, I/O circuitry, and a 
BIA. The microprocessor that was selected for the controllers Is a Texas 
Instruments 9900 unit with 64K bytes of memory capacity. Up to 20K of the 
memory can be read only memory (ROM) with the remaining portion random 
access memory (RAM). The microprocessor, memory, and I/O circuitry were 
assembled from commercially available Texas Instruments printed circuit 
cards. The BIA Is being developed on a TRW Internal research and develop- 
ment program. The cards are assembled as a unit In a Texas Instruments TM 
990/530 s1xteen-s1ot card chassis mounted In a commercial 19-Inch rack. A 
picture of the overall system Is shown in Figure 2-2. 

2.6 STUDIES AND ANALYSES 

A series of studies and analyses were performed to develop the details 
of an effective WS for the 250-kilowatt power system: 

a) Autonomy; the evaluation and selection of onboard 
control rather than terrestrial control. 

b) Hierarchy; the development of a distributed approach to 
control processing rather than a central computer 
control . 

c) Data Network: the evaluation and selection of a global 
bus architecture for communication among the PMS 
distributed controllers. 

d) Operational Strategies: the evaluation of r.everal 
operational options utilizing the PMS to '•educe power 
system operational costs (I.e., equipment resupply). 

These studies developed an effective PMS concept for the Implementa- 
tion of large complex power systems (250-kilowatts). In addition, major 
advantages and benefits from power management were Identified and quanti- 
fied. Life cycle costs of space power can be reduced, power availability 
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Is enhanced as the safe haven operation Is essentially avoided, and the 
spacecraft electrical power system bec(»nes user friendly - a utility. 

2.6.1 Autonomy 

Automated control may be Implemented by onboard in-flight computa- 
tional capability (autonomous control) or by commend and data telemetry 
between the spacecraft and a terrestrial control center with the conputa- 
tlonal capacity. Autonon^ Is required for rapid response to malfunctions 
or when the spacecraft or satellite communication time Is protracted (by 
distance or orbit view angle). However, a safe haven mode may be imple- 
mented for these conditions. To more fully evaluate these options, a cost 
trade was performed to compare autonomous operational costs with terres- 
trial control costs (F1gt"'e 2-3). The projected costs Included: (1) the 

additional onboard microprocessors for autonomous operation, (2) the 
expanded telemetry equipment for command and data transmission for terres- 
trial control, (3) the projected costs for one dedicated ground station for 
terrestrial control, and (4) the estimated annual labor costs. Based on 
these costs, the autonomous approach provides a significant economic bene- 
fit both Initially and over a protracted time period. 

2.6.2 Power Management Subsystem Hierarchy 

Trade-off studies were performed to determine the control hierarchy 
for the PMS within the electrical power system. Centralized, distributed, 
and several hybrid concepts were considered. The three-tier hybrid concept 
(Figure 2-4) was selected as the recommended hierarchy. This selection 
requires modest computational power In each controller, provides a well- 
defined Interface with the spacecraft and other subsystems, provides sub- 
system autonomy for assembly, testing, and algorithm development, minimizes 
the quantity and distance of sensor data transfer. Incorporates subsystem 
control to simplify controller Interactions and communications, and accom- 
modates growth in both energy storage (nunber of channels) and load center 
quantity. 

2.6.3 Data Network 

A global bus architecture was selected as the data bus concept for the 
power management system because of Its flexibility, reliability, failure 
tolerance, data rate accommodation, and equipment economy. This 
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architecture uses « single twisted pair electrical path (or single optical 
path) to minimize wiring between controllers. In this scheme, any single 
controller can ccmmunlcate directly with any other controller on the data 
bus. Broadcast messages to all controllers can also be transmitted. The 
architecture works In conjunction with a distributed-control , time- 
sequential data bus contention resolution scheme and the Internat1<)nal 
Standards Organization (ISO) high-level data link control (HOIC) data bus 
protocol to provide the overall date communications design. The global 
architecture Is Inherently flexible. Growth of the data ous systm and/or 
^Iflcatlon of the system topology Is easily accomplished by simple addl- 
tlor* (or deletion) of the related BIA units and the associated data bus 
wire length without disturbing existing equipment on the bus and data bus 
routing. 

2.6.4 Operational Strategies 

Two operational strategies were Investigated to reduce resupply costs' 
battery depth of discharge control and thermal fluid pianp control. Poten- 
tial cost savings are beyond $5M for balanced battery operation (Flqur* 

2-5) and $5M for matching pump operation to the load oroflle (Figure 2-6). 

2.7 CONCLUSIONS 

The autonmioui power management task of this study established the 
need for electrical power system management, developed a power management 
subsystem concept. Identified the major algoritlwis for power system con- 
trol , assessed the r.tatus of the supporting technology, and Initiated a 
deiiK)nstrat1on of tr.e management concept through software development of 
representative algorithms and assembly of breadboard hardware. The power 
management subsystem controller was developed for the 250-k11owatt refer- 
ence electrical power systmn for a large space platform In low earth orbit. 
This management concept Incorporates flexibility for modular power growth, 
payload variety and growth, and spacecraft m1ss1(W) redirections. Conse- 
quently, the power management concept Is adaptable to a wide variety of 
satellite applications and missions with a broad range of power levels, 
distribution voltage levels and forms, energy storage devices, and pwer 
source types. 
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The power management concept utilizes a decentralized data processing 
approach to achieve autonomous operation of the electrical power system. 

The power management algorithms were Identified, and software development 
was Initiated for the load bus asslgnn^t, load switch command processing, 
and switch gear monitoring algorithms. Denwn strati on of the power manage- 
ment system was Initiated with assembly of an electrical power subsystmn 
controller breadboard and a load center controller breadboard. 

Power management provides a means to integrate and control effectively 
a large number of smaller pmter sources and energy storage devices and 
distribution equipment into a cohesive multi -hundred-kilowatt electrical 
power utility. This method of electrical power management inqilementation 
(algorithms and controller hardware) provides an attractive approach to 
near-term readiness for large space generation and applications. Develop- 
ment of very large power generation and energy storage elements and the 
corresponding very high current switchgear that would be required to 
achieve a multi -hundred-kilowatt electrical power system Is thereby avoided. 
Consequently, power management Is an enabling technology to near.term multi- 
hundred-kilowatt availability of electrical power systems for spacecraft. 

The hardware of the power management subsystem is modular In nature 
which provides great system flexibility. Incremental assembly and future 
expansion of a power system Is supported with minimum development and 
expansion costs, and resupply costs are reduced. Furthermore, the modular 
approach allows application of this power management concept to a broad 
range of system power ratings (50 to 500 kilowatts). 

The application of autonomous power management technology Is cost 
effective and provides enhanced operation: 

a) Ground station support costs are reduced, and cormnunl cation 
traffic requirements are minimized. 

b) Degradation and/or failure modes are quickly and efficiently 
accommodated so that power availability to the payload Is 
enhanced (minimizes safe haven occurrences). 

c) Power generation and energy storage are capable of full utili- 
zation to maximize payload support. 

d) Equipment life may be enhanced by Implementation of automated 
operational strategies. 
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e) Acquisition of trend data and analyses thereof provide 

degradation and resupply projections to optimize refurbishment 
scheduling and minimize replacement occurrences yet maximize 
the aggregate power availability to payloads. 

2.8 RECOMMENDATIONS 

Technology developments for the PMS fall Into two categories: a1go> 
rithm development ami hardware development. Of these, algorithm develop- 
ment for the EPS (management strategies and operational control laws) will 
require the longest time, and thus Immediate effort thereon Is urgently 
needed. The Implementation of these preplanned decisions and operational 
strategies Is critical to enable development and operation of large capa- 
city power systems by combining and controlling numerous smaller capacity 
power components Into a utility-type EPS for multi -hundred-kilowatt power 
levels In space. 

Hardware development of microprocessors Is progressing rapidly due to 
data processing requirements In the comMrclal sector. Although only one 
radiation hardened microprocessor Is available at this time, several CMOS 
processors are coming on the market that appear adequate for multl- 
hardware-kllowatt power management systems. Data bus protocols are being 
developed by the commercial sector (for distributed processing applications 
In banks, airlines, etc.) that appear to be more than adequate for applica- 
tion to the power management system. 

A large quantity of sensors Is required to monitor the operation of a 
multi -hundred-kilowatt EPS subsystem for autonomous control; because of the 
large quantity, a need exists to develop lightweight, low power, accurate 
sensors for current and pressure data. Present devices are typically 
heavy, c(Wisuffle modest power, and provide accuracy of only 2 to 3 percent of 
full scale. Such accuracy Is marginal for some control functions (e.g., 
battery charge control). 
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3. SCOPE 


The goal of automated power management is to provide a payload- 
friendly, utility-type electrical power system in support of future space 
platforms and space stations. The autonomous power management task of this 
study is therefore structured to; 

a) Establish the need for electrical power system management by 
identifying the risks and benefits of power management 

b) Develop a management concept for high-power satellites using 
the 250-kilowatt power system as a reference 

c) Assess the status of technology to support electrical power 
management consistent with a 1985-86 technology read ness, and 
Identify technology drivers 

d) Identify the major management strategies (algorithms) to con- 
trol a complex electrical power system 

e) Demonstrate the power management concepts by software develop- 
ment of representative algorithms and through assembly of 
breadboard controller hardware. 

Trade studies, analyses, and evaluations are performed to develop the 
concept of an autonomously managed power system based upon the 250-kilowatt 
electrical power system reference design. Subsequently, the design and 
development of the essential hardware components of the power management 
subsystem are initiated, and the development of representative algorithms 
is initiated. 
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4. REQUIREMENTS DEFINITION 


This section describes the set of requirements that are pertinent to 
the development of the PMS. These requirements include the general system 
requirements for the EPS and functional requirements for the PMS. The 
functional requirements for the PMS include operational, maintenance, and 
degradation/fault accommodation requirements. 

4.1 ELECTRICAL POWER SUBSYSTEM REQUIREMENTS 

The EPS requirements are the general requirements that define the 
EPS operational constraints. 

4.1.1 Purpose 

The EPS is a part of a large space platform whose purpose is to pro- 
vide utility type electrical power (250 kilowatts) to a variety of 
undefined payloads. A utility-type power system is defined as one that 
provides electrical power from more than one energy source to a set of 
undefined payloads. 

4.1.2 Mission Capability 

The spacecraft will operate in low earth orbit (90 minute orbit, 36 
minute eclipse) and be capable of servicing a wide variety of missions. 
Specific missions will be determined by the nature of the payloads. 

4.1.3 Modes of Operation 

The spacecraft will have two main modes of operation; 

a) Manned operation with shirt sleeve environment for indefinite 
periods of time with periodic shuttle refurbishment 

b) Autonomous, unmanned, and unattended operation for an 
indefinite period of time. 

4.1.4 Operating States 

The spacecraft will operate in predictable states and will be con- 
trolled by autonomous on-board management, with optional on-board command 
or ground command overrides. ^ 
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4.1.5 Rellabll Ity 

Three main reliability requirements will be applied: 

1) Safety redundancy: The power system will be reliable to the 
point that life support requirements are met. 

2) Mission Redundancy: No single point failure will fall the 

mission. However, partial power outages will be allowed and 
accommodated by r^undant power buses. 

3) Life Redundancy: Proper component deratings and high relia- 
bility parts will be Incorporated. Failed equipment will be 
replaced via space shuttle refurbishment. This policy will 
provide extended operational lifetime of 30 years and longer. 

4.1.6 Environmental 


The spacecraft will be designed to space shuttle launch requirements 
with normal spacecraft design temperatures. 

4.1.7 Output Capability 

The EPS will be capable of providing 250 kilowatts to an undefined 
number of loads. The power systmn will be flexible In nature and capable 
of expansion. 

4.2 POWER MANAGEMENT SYSTEM FUNCTIONAL REQUIREMENTS 
4.2.1 Configuration 

The PMS win be configured as shown In Figure 4-1. The PMS will be 
capable of providing two levels of management. The top level of management 
provides the overall EPS management and Interfaces with the spacecraft con- 
troller. The second level of management consists of power source manage- 
ment and load center management. 

These management areas will perform the following specific functions: 

a) Monitoring functions that measure the system parameters. 

b) Processing and decision functions that perform the sorting, 
transformation, manipulation, and Interpret at 1 (mi of data and 
that determine which monitoring, control, and recording func- 
tions are to be executed. 

c) Control functions that execute the desired changes to the 
network configuration. 
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Figure 4-1. Power Management Subsystem Configuration 
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d) Recording functions that preserve the data needed for 
operational, trend projection, and fault analysis. 

4.2.2 Scope of Responsibility 

The PMS will provide the managenient of the complete EPS from power 
generation to loads by: 

a) Decoding and executing commands from the central spacecraft 
controller 

b) Acquiring power system data for on*board analysis and partial 
ground telemetry 

c) Providing timing for synchronization of power system events 

d) Providing high level processing for computational purposes, 
progrmn and data storage, and execution of management of power 
sources and load centers. 

4.2.3 Power Source Hanagement Functional Requirements 

Power source management provides the necessary monitoring, processing, 
decision, control, and recording functions for the power generation, energy 
storage, and switching devices and their associated power electronics hard- 
ware. The requirements that determine the Implementation of the power 
management functions fall Into the three main categories of operations, 
maintenance, and degradatl on/fault accomnwdatlon requirements. 

4.2. 3.1 Power Source Operational Requirements 

The major operational requirement for power source management Is to 
manage power generation and battery operation to support the loads and to 
recharge the power subsystem batteries. The power management system will 
provide a method to char^ each nickel -hydrogen battery Individually In the 
power subsystem based on a low-earth orbit mission. The charging algorithm 
win operate In conjunction with the energy planning algorithm at the EPS 
management level to provide a charging cycle that may be orbital or multi- 
orbital. The algorithm will provide a means to determine the state of 
charge of each battery at all times. Battery current, voltage, pressure, 
and temperature will be nmnitored. Battery charge current will be con- 
trolled based on the state of charge of the battery by varying the solar 
array output current (l.e., the number of solar cell string segments 
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connected to each battery bus). The battery paraaieters, including the 
battery state of charge, will be stored. 

4.2. 3.2 Power Sourc. Maintenance Requirements 

The major maintenance requirement for power source management is to 
maintain the state of health of each battery by analyzing battery perfor- 
mance during normal operation, performing periodic reconditioning, and 
making trend projections to determine when the batteries must be replaced. 
The reconditioning algoritlmi will work In conjunction with the energy 
planning algorithm to determine when reconditioning can be performed during 
the mission. The algorithm will perform both a charge and discharge recon- 
ditioning routine. Battery cell analysis will be performed during normal 
operation as well as the reconditioning routines. The cell analysis will 
be based on a statistical distrlbutim of cell voltages. Battery current, 
temperature, cell voltage, and pressure will be monitored. Battery charge 
current will be monitored according to the cell analysis results. Cell 
anomaly data will be stored along with the associated battery current and 
temperature. 

Battery trend projections will predict degradation and determine 
battery replacement needs based on an analysis of battery age, capacity, 
and cell data. An alert will be sent to the ground when a required battery 
replacement Is approaching. Sufficient trend data will be stored for 
answering ground Interrogations. 

4. 2. 3.3 Power Source Degradation/Fault Accommodation Requirements 

The PMS will determine degradation of the solar array, solar array 
switching unit, and batteries. Solar array degradation will be determined 
by measuring Its available output power at a predetermined battery voltage. 
Degradation of the solar array switching unit will be determined by 
accounting for any solar array switches that have failed. Battery degrada- 
tion will be determined from cell analysis data. Remedial battery recon- 
ditioning will be scheduled based upon degradation data. Battery capacity 
will be determined and sent to tlw energy planning algorithm at the EPS 
management level to accommodate load management. All status Information 
will be stored within the PMS. 
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4.2.4 Load Center Managefiwnt Functional Requirements 

Load center management provides the necessary sensor monitoring, data 
processing, and decision, control, and data storage functions for the power 
distribution circuitry and the power conditioning circuitry (if required) 
located in the spacecraft load centers. The requirements that determine 
the Implementation oT the power management functions fall Into the three 
main categories of operational, maintenance, and degradation fault accommo- 
dation requirements. 

4.2.4. 1 Load Center Operational Requirements 

The major operational requirement for load center management Is to 
distribute power to each of the load buses. The PMS will provide commands 
to programmable resettable circuit breakers that will allow for con^iectlon 
of the load bus to selected power channels. The status of each circuit 
breaker will be monitored and stored. Also, c(»nmands will be provided to 
set circuit breaker trip points. Switch currents, channel currents, and 
load bus voltages will also be monitored. 

4. 2. 4. 2 Load Center Maintenance Requirements 

The major maintenance requirmnent fcr load center management Is to 
monitor circuit breakers and sensors within the load centers for failures. 
The status of failed circuit breakers and sensors will be gathered In the 
load center and this information will be transmitted to the EPS controller 
via the data bus. 

4. 2. 4. 3 Load Center Deoradatlon/Fault Accommodation Requirements 

The major degradatlon/faulf. acccmmodatlori requirement for load center 
management is to detect failures of the circuit breakers and sensors within 
the load centers. The power management system will be capable of detecting 
the status conditions listed In Table 4-1. Fault information will be 
transmitted to the EPS controller for EPS state-of-health monitoring. 

4.2.5 Electrical Power Subsystem (EPS) Manage:-?nt 
Functional Requireroefts 

EPS management provides the necessary monitoring, processing, deci- 
sion, control, and recording functions of the overall power subsystem. The 
requirements that determine the Implementation of the power management 
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Table 4-1. Load Center Status Conditions 


Status Type 
0 
1 
2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 


Status Condition 
No fault, load on 
No fault, load off 
Breaker open 
Breaker closed 
Breaker status open 
Breaker status clost'd 
Current transducer, no output 
Current transducer, full output 
Load undercurrent, min 

Load overcurrent, max 

Voltage transducer, no output 
Voltage transducer, full output 
Bus undervoltage, Vj^ < Vj^ min 
Bus overvoltage., > V^^ max 
Last coflmand off 
Last command on 
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functions fall Into three main categories of operational, maintenance, and 
degradation fault accoRiT>odat1on requirements. 

4.2.5. 1 EPS Operational Requirements 

The major operational requ1r«nents for EPS management are to provide 
energy balance for the power subsystem and to assign the load bus locations 
to the power channels. The power management system will provide an ade- 
quate energy balance for each channel and for t'.te overall system. The 
energy balance algorltlm will be operative during both sunlight and eclipse 
modes of operation to provide prope- battery charging. Both orbital and 
multlorbltal energy balance routines will be provided. The power manage- 
ment system will provide the capability to deactivate nonessentlal loads on 
a priority basis and to notify the spacecraft computer If proper energy 
balance cannot be attained. The energy balance bigoritlmi will determine 
the desired loading on each power channel. 

The load assignments function will determine the distribution system 
configuration which minimizes the mismatch between the desirable cha;tnel 
loading and that which Is physically realizable. The power management 
system will be capable of making the load assignments based on system 
priorities and constraints such as the switchabll Ity of loads and the noise 
sensitivity of the loads. The load assignments function will be capable of 
determining that the selected conflguratlc^ has been Implemented. If the 
selected configuration has not been Implemented, the load assignments 
function will be capable of reassigning the loads based on the new system 
constraints. * 

4. 2. 5. 2 EPS Maintenance Requirements 

The power management system will determine the overall state of health 
of the power subsystem. The pwver management system will Identify when 
wearout of power subsystem con^onents Is imminent based on the subsystem 
state of health and will alert the ground station of these projections for 
subsequient replacement schedules. *he power management system will store 
sufficient trend data to answer ground Interrogation of the projected 
replacement requirements. 
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4. 2. 5.3 EPS Deqradat1on/FauU Accowwodatl on Requirements 

The power managenent system will determine the overall state of health 
of the power subsystm. information will be received fr«n the power source | 

and load center controllers based on degradation/fault accommodation 
requirements for these management areas. The EPS controller will maintain 
status tables for all electrical power subsystem operating condltlonsk. The 
power management system will be capable of modifying system conditions such f 

as performing emergency load shedding in order to maintain the electrical 
power subsystem In a proper state of health. The power management system 
will be capable of reallocating solar array power between power channels in 
order to maintain the electrical potmtr subsystem In a proper state of 
health. 1 f 

The power management system will be capable of determining failures 
within the power source, load center, and EPS controllers and of maintain- 
ing the system data bus In a proper operating condition. 

4.2.6 Summary of Management Requirements and Functions 

A summary of the requirements In each of the major management areas Is 
presented In Table 4-2. The major functions that must be performed to meet 
each of the management requirements are also listed. 
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5. ALGORITHM DEVELOPMENT 

In the development of an autonomous power management subsystem, the 
functions that are to be performed in the electrical power subsystem must 
be transformed into algorithms. Algorithms are the defined processes, 
rules, or procedures that are assigned to the functions to assure the 
realization of a desired output from a given input. Usually, algorithms 
are a sequence of formulas and/or algebraic logical steps that calculate or 
determine a given task. 

5.1 ALGORITHM DEVELOPMENT APPROACH 

The general approach to developing algorithms is shown in Figure 5-1. 
The first activity is to define the system level requirements. These 
requirements include system level /operational requirements, electrical 
power subsystem functional requirements, performance requirements that are 
initially knwn, and system- imposed constraints. The requirements are 
defined by gathering inputs from various disciplines, such as operations, 
integration and test, environmental, components, subsystems, and the 
customer. 

The next step is to define the top-level functions that must be per- 
formed in order for the system to meet the defined requirements, and to 
group the functions logically according to their interactions. Interfaces 
between these functions are defined as well as information or data flow 
between functions. The functional areas are fully described along with a 
first level of functional decanpoeition. 

The next step is the detailed design activity which involves the 
examination of the functions and information structures defined previously, 
the expansion of the general functions expressed therein to provide more 
detail, and the grouping of this detailed information into subfunctions and 
their interfaces. This process proceeds through several iterations to the 
point where functional decomposition becomes procedural decomposition, 
i.e., where functions are described in terms of algorltNns which affect 
them, and information structures are described in terms of data structures 
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used by the algorithms. This Iterative design process Incorporates several 
well-known techniques; 

a) Stepwise refinement. The sequence of steps which repeatedly 
breaks up tasks Into subtasks and similarly refines data 
structures. 

b) Top-down design. Beginning with a firm, fixed requirements 
specification, top-dovm design organizes and develops the 
control structure of a prog, am through stepwise refinement. 

c) Hlerarchlal decomposition. Provides guidelines on the amount 
of additional detail betwe<^.n successive refinement steps. 

d) Modularity. Provides gu1d**iines on the passing of information 
among functions on a given level (Reference 5-1). 

Impl enentatl on and testing i’ollow the detailed design. Implementation 
Involves writing the algorithms in a computer programming language or code. 
Testing Is performed to ensure that the system works according to the 
design requirements. Testing of software Is usually performed bottans-up 
starting with Individual modules. The modules are gradually Integrated 
together until the entire system Is tested. Testing removes both program- 
ming language and logic errors that were Introduced during the Imple- 
mentation stage. Testing usually Involves running the program through all 
possible combinations of Input and output constraints. 

The last step Is maintenance which Is performed after delivery of the 
system to the user. Maintenance consists of on-site debugging to correct 
errors that were not detected during the testing stage and software 
upgrades to add new functions to the system. 

The overall algorithm development approach is an Iterative process In 
that each succeeding step may supply Information and place additional con- 
straints on the previous step. For example. It may be determined during 
the detailed design phase that certain functions should be done In hardware 
rather than software. This change could affect the function definition as 
well as the requirements definition step, 

5.2 AUTONOMOUSLY MANAGED POWER SYSTEM (AMPS) ALGORITHMS 

The major algorithms to be Implemented In the autonomously managed 
power system are listed In Table 5-1. These algorithms were derived 
directly from the functions that are to be performed In the electrical 
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Table 5-1. List of Algorithms 
Electrical Power Subsystem Management 

• Energy Planning and Allocation 

- Solar Array Power Reallocation 

• Load Bus Assignments 

• Power Subsystem State-of -health 

- Replacenwnt Scheduling 

- Controller Anomaly 

Power Source Hanagen»nt 

• Battery Charge Control 
t Battery State-of -Health 

- Reconditioning 

- Trend Projection 

• Solar Array Status 

- SASU Switch Status 
Load Center Management 

t Command Processing 

- Circuit Breaker Programming 
t Switch and Load Bus Monitoring 

- Fault Definition 
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power subsystem, as shown In Table S-1. These algorithms are grouped Into 
the three main categories of power source management, load center manage- 
ment, and electrical power subsystem (EPS) management. 

In general, a first Iteration of each algorithm was developed to the 
functional definition, a step described In Section 5,1. Portions of the 
load bus assignments, command processing, and switch and load bus moni- 
toring algorithms were developed through the Implenentatlon and testing 
stages. These algorithms were developed In order to verify operation of 
the load center controller and electrical power subsystem controller that 
were developed during this phase of the program as described In Section 7. 
These algorithms were Implemented in FOR'll, a high level programming lan- 
guage that was determined to be best suited tor the AMPS application (see 
Section 8.7). Each of the algorithms Is described In the following 
sections. 

In addition to the functional algorithms listed In Figure 5-1, each 
controller requires an executive algorithm. The executive algorithm man- 
ages the overall operation of the controller. Functions provided by the 
executive are process scheduling, mana^nent of common data buffers, timer 
services and data bus Interface adapter (BIA) interfacing. The executive 
algorithm Is described further In the following sections. 

5.3 POWER SOURCE MANAGEMENT ALGORITHMS 

The power source management algorithms provide the processes and 
procedures for the functions required to operate the power generation and 
energy storage devices and their associated power electronics hardware. 

The major algorithms are battery charge control, battery state of health, 
and solar array status. These algorithms are described In the following 
sections. 

5.3.1 Battery Charge Control Algorithm 

The 250-kilowatt power system Includes nickel -hydrogen batteries for 
energy storage, A three-level charging approach Is employed to recharge 
these batteries: 

a) A high-rate charge essentially utilizing the net available 
power from the solar array (gross power output less loads) 
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b) A reduced charging rate suitable to essentially complete the 
battery recharge but at a safer rate to approach overcharge (an 
Intermediate charge rate) 

c) A trickle charge rate acceptablt for overcharge during an 
entire sunlight period. 

A battery charge control algorithm Is employed to define and control the 
transfer to the next appropriate charging rate. Two approaches to battery 
charge control are provided for redundancy: (1) a state-of-charge control, 

and (2) a recharge fraction control. 

The primary control method (Figure 5-2) Is based upon state of charge 
as the basis for changing charging rates (high rate, Intermediate rate, 
trickle rate). Meaningful state-of-charge calculations require knowledge 
of the Instantaneous efficiency. Accordingly, efficiency Is determined. In 
real time, by comparing the measured cell pressure data with the theoreti- 
cal pressure calculated assuming 100 percent efficiency. Hence, cell pres- 
sure data Is required for this approach. 

Four maj^r processing steps are used to assemble the charge control 
algorithm (Figure 5-2): 

1) “Current sense" to determine the battery op, 'rating mode, 
recharge (+) or discharge (-) 

2) "Increment Ah, SOC" to update the battery charge status 

3) "SOC SOC 1" or similar test to trigger transfer to another 
charge” rate 

4) "Switch to trickle charge rate" or similar step to Implement 
the transfer to the specified charge mode. 

These building block steps are arranged In logical order (Figure 5-2) pro- 
ducing a series of four sub loops defining high-rate charge. Intermediate 
charge, trickle charge, and discharge. In addition, a check of the level 
of overcharge attained Is made, and the Intermediate charge parameters and 
limits are adjusted accordingly. Also, initial parameters are defined for 
a fully charged battery. This precludes long term rundown of a battery due 
to Inherent imperfections In the cumulation of Incremental state-of-charge 
calcul atlons. 

This algorithm Is continuously operational, but Interrupts occur at 
each "Increment" block during the time delay period. This allows 
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Figure 5-2, Battery Charge Control Algorithm Flow Diagram 
(State-of -Charge Method) 
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micro-processor time for other operations. After the time delay, the 
program resumes at the same point in the charge control algorithm. Execu- 
tive control within each power source controller coordinates these inter- 
rupt operations. 

The alternate charge control method is based upon ampere-hour integra- 
tion without compensation for inefficiency of recharging. This control 
method (Figure 5-3) is structured similarly to the state-of-charge control 
method. However, this method utilizes ampere-hour calculations, accumula- 
tion, and comparisons for control decisions. State-of-charge calculations 
and the necessary efficiency determination from measured cell pressures are 
avoided. Hence, this method requires only battery current measurements. 

These algorithms address control of normal batteries. Should abnormal 
cell operation develop (as determined from cell voltage and pressure mea- 
surements), charge control parameters (not the algoricfwt structure) are 
modified appropriately. 

5.3.2 Battery State-of -Health Algorithm 

The battery state-of-health algorithm has the following objectives: 

a) To identify anomalous cell and/or battery performance 

b) To save the data describing the anomalous performance 

c) To identify anomalous situations requiring remedial action 

d) To provide a historical data file for subsequent diagnostic 
evaluation. 

The nature of a utility-type electrical power system precludes the 
assumption that the power profiles during any two discharge/recharge cycles 
are alike. This also precludes any simple trend analysis as the discharge 
rates and depth of discharge reached can vary significantly from cycle to 
cycle. A statistical approach to trend analysis witn this data base 
requires complex modeling of each conceivable failure mechanism, its effect 
on performance parameters, and combinations thereof. However, simplified 
techniques to perform trend evaluation are included in the battery state- 
of-health algorithm. 

Two approaches to identifying anomalous performance are utilized in 
the algorithm (Figure 5-4). In the first, a dispersion test, the measured 
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Figure 5-4. Battery State-of -Health Algorithm (Anomaly Detection) 


















34579-6001 -UT-00 



attrl butts of voltage, current, pressure, and temperature for the 160 cells 
are taken over a relatively short time span, within several seconds. This 
set of 160 cell voltages, temperatures, and pressures are assigned to be 
distributed statistically normal provided the current was stable during the 
measurement interval. Therefore. Individual values more than three* stan- 
dard deviations from the mean represent anomalous cells. This dispersion 
approach, repeated approximately every minute, has the advanta^ of Inde- 
pendence of the d1 scharge/ recharge rates and depth of discharge Imposed by 
varying power profiles. The approach Is shown graphically In Figure S-5 
for cell voltage analysis. Caparison of anomalous performance from one 
discharge/ recharge cycle to others having differing power profiles Is 
Invalid for trend analyses, hoover. Consistent discharge/recharge rates 
and depth of discharge (same power profl-r) from cycle to cycle are 
required for valid trend analyses. 

The second approach postulates provir .ng periodically a standard test 
cycle of essentially constant load current to a specified depth of dis- 
charge. This standard test load Is provided by selectively allocating 
payload buses of essentially constant profile to t1« battery on test. 
Assimlng one battery (of the 17 batteries In the 250-kllowatt system com- 
plement) Is so loaded each eclipse cycle, each battery Is evaluated by the 
standard test cycle once every 25.5 hours. The performance data from this 
standard test cycle are compared with the data of prior standard test 
cycles. Trends of cardinal data points such as mid-point and end-point 
values of the performance parameters are calculated and projected. Trends, 
exceeding predetermined acceptance ranges, are noted as anomalous. Data on 
these anomalous trends are stored for transfer to a ground station file for 
historical records and any further In-depth analyses deemed appropriate. 

5.3.2.1 Files 

Cell data and battery parameters are stored In three files: (1) a 
temporary on-board file, (2) an on-board rollover file, and (3) ground 

The actual limiting value for the acceptable spread from the mean requires 
determination from test data on nickel -hydrogen cells. (A large valie for 
the standard deviation for voltage or pressure suggests general r.eP unbal- 
ance and reconditioning 1$ required.) 
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station file. A fourth file, containing anomaly data. Is utilized for 
on-board trend analysis to select the proper corrective action response. 

The temporary on-board file stores voltage, pressure, and temperature 
data for each cell, and voltage and current data for the battery for one 
recharge cycle and the subsequent discharge cycle. This results In 43,470 
data points asstmilng one data scan p'^r minute: 90 x (160 cells x 3 data 
parameters plus two battery parameters plus a time mark) « 43,470. This 
data Is used for tN dispersion tests to Identify anomalous performance 
(approach one). Upon completion of a discharge cycle, the data Is purged 
unless there Is an anor^lly. In that event, the d;ca Is transferred to 
telemetry storage for transmission to tlw ground control station for 
anomaly history records, rnd the dat^' of the anomalous cell is stored 
on-board In the anomaly data file. 

The on-board rollover file retains the pertinent paraiMters from the 
standard test cycles for trend analyses and predictions (approximately one 
cycle per day). This data Includes mid-point and end-point values for the 
cell parameters of voltage, pressure, and temperature and for the battery 
parMeters of current, voltage, and depth 'if discharge. This results In 
13,552 data points assuming seven sets of standard test charge/discharge 
cycles are recorded for statistically significant trend analyses and 
projections: 

(160 cells X 3 data parameters * 3 battery parameters -f time mark) 

X 2 for mId-poInt/end-poInt data sets 
X Z for charge /discharge data sets 
X 7 cycles 

■ 13,552 data points 

As new data is subsequently gathered and added to tl« file, the oldest data 
set In the file 1$ discarded or transferred to telemetry storage for trans- 
mission to the ground control station for a historical record of trend 
data. 

The rollover file gathers, in addition to the standard test cycle 
paraMters, battery end-of -charge voltage and temperature (a mean value) 
and the depth of discharge (ampere-hours removed) for each eclipse cycle. 
This data requires only 3 bytes plus an Identifying word (2 bytes) per 
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ecMpse cycle. This requires a 640-byte field in the rollover file to 
accoflvnodate 8 days of 16 eclipse cycles/day. As subsequent new data is 
gathered, the older data of this file block is transferred to telemetry 
storage for transmission to the ground control station (or discarded). 

These parameters provide a modest, but significant, history of normal 
performance cycles with little impact on file space requirements. 

The ground station file is intended to produce a historical record as 
an expanding data base of nickel -hydrogen experience. The file receives 
three data types: 

1) The periodic standard test cycle parameters frwn the on-board 
rollover file. 

2) The charge/discharge parameters of those cycles having anoma- 
.lous cell dispersions. 

3) The end-of -charge battery voltage and temperature and depth of 
discharge for each operational battery cycle. 

In addition, the ground control station may request the on-board temporary 
file data at the end of each charge/discharge cycle even when performance 
is normal. Such a request provides a complete and nearly continuous read- 
out of battery and cell performance. 

Data for 30 days of operation aggregates approximately 60,000 bytes 
per battery, approximately 1,020,000 bytes per spacecraft with 17 batteries 
(250-kilowatt baseline). This is reasonable for terrestrial storage tech- 
niques (disk storage). The battery data must be accumulated and stored in 
an orderly and readily retrievable mode over the life of each battery. 

This data aids the battery engineers in evaluating battery problems and 
defining the appropriate corrective actions. This data is not intended for 
continuous status monitoring and plotting by ground personnel. 

5. 3. 2. 2 Data Compression 

The battery and cell data required to diagnose performance correctly 
is voliminous. Several techniques are available to reduce the file space 
required for this data storage; 

a) Use 8 bits (byte) instead of 16 bits (word) for parameter value 
recording. 
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b) Use statistical canpresslon of the data points, i.e., calculate 
and save the mean and standard deviation rather than save every 
data point. 

c) Apply a bit compression algorithm to reduce the bit quantity in 
the data from many 8-b1t groups (the parameter bytes) to fewer 
nongrouped bits. Compressions of 3:1 to 20:1 have been real- 
ized with this technique. 

Battery and cell paran»ters are defined as 8-bit values herein. The 
8-bit value provides a digital resolution of 1 count in 256 counts 
(0.4 percent). Transducer accuracy is typically only 1 to 3 percent. 

Hence 1-byte data parameters are adequate. 

Cell and battery data parameters aggregate approximately 58,000 bytes 
of on-board memory capacity. Typical processor memory space is 64K bytes 
without expansion provisions or bulk storage addition. The remaining 6K 
bytes is projected to be marginally adequate for battery control programs 
considering that the battery control software used on another study is 
implemented with approximately 3K bytes of program memory and can be purged 
to approximately 2K bytes. Additional program file space of 14K bytes is 
potentially available by reducing the temperature data from one recorded 
measurement per cell (160 per battery) to four parameters per battery (mean 
value, standard deviation, highest temperature, and lowest temperature). 
This provides a generous 20K-byte program file. Selection of any specific 
data compression or bit compression approach is left to subsequent studies. 
Additional bulk data storage may be as cost effective as these compression 
techniques. 

5.3.3 Solar Array Status 

Each of the 17 channels of the power subsystem contains a portion of a 
solar array switching unit that switches solar array sections to regulate 
the solar array outputs with either a current or voltage as the controlling 
parameter. The solar array panels are subdivided into many sections inter- 
connected by solid-state switches. The solar array status algorithm moni- 
tors the solar array sections for failures, determines output capabilities, 
and makes degradation projections. The current and voltage of selected 
array sections and the array switch status are monitored. 


59 


34579-6001-UT-00 


5.3.4 Power Source Management Processing Requirenients 

The power source management algorlt^s were evaluated to determine the 
computer processing requirements In terms of the nimiber of Instructions/ 
second that are needed to perform the algorithms. This analysis required 
determining the rnmiber of times per minute that the algorithm must be 
repeated (monitor rate) and the total number of programming instructions 
required to define the algorithm. This analysis Is summarized In Table 
5-2. 


Table 5-2. Power Source Management Processing Requirements 


Functi on 

Instructions 

per 

Function 

Repetition 

Interval 

(sec) 

Controller 

Instruction 

Rate 

(Instr/sec) 

System* 

Instruction 

Rate 

(Instr/sec) 

Battery State of 
Health 

83,100 

20 

4,155 

70,635 

Battery Charge 
Control 

7,100 

2 

3,550 

60,350 

Solar Array 
Status 

3,500 

20 

175 

2,975 



7,880 

133,960 


H 

Seventeen controllers In 250 kW system. 


The monitor rates are based on the 90-m1nute orbit that was defined 
for the spacecraft (see Figure 5-6). The orbit Is further defined as 
having a 36-minute eclipse period along with a 54-m1nute daylight period. 
Battery charging must be closely controlled during finish charge and 
trickle charge in order to avoid excessive overcharging or battery run- 
down. This trimming of the battery overcharge ratio (100 to 110 percent 
range) requires a state-of-charge Integration accuracy of 1 percent over 
the charge and discharge cycles. The monitoring rate Is therefore dictated 
by the eclipse period since it Is the shortest period. The calculated 
monitoring rate requirement Is then 36 minutes divided by 100 or approxi- 
mately one sample every 20 seconds. In order for the measured parameter 
(battery current) not to Inject additional error Into the required 
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measurement accuracy, the monitoring rate of the battery current was 
Increased by an order of magnitude over the 20-second requirement to one 
sample every 2 seconds. 

’ 

The battery state of health and splar array status algorithms are 
perfomwd every 20 seconds to accnnmodate the I percent accuracy require- 
ment, Also battery cell monitoring at the end of the discharge cycle 
requires monitoring In the 20-second time frame to ensure that some cells 
are not conq)letely discharged and reversed. 

The number of instructions required to perform the algorithm were 
calculated based on past experience In programming similar algorithms for 
spacecraft applications. 

5.4 LOAD CENTER MANAGEMENT ALGORITHMS 

The load center management algorltims provide the processes and proce- 
dures for the functions required to operate and monitor the power distribu- 
tion circuitry and the pov«r conditioning circuitry (If required) that Is 
located in the spacecraft load centers. The major load center management 
algorithms are command processing and switch and load bus monitoring. 

These algorithms are described In the following sections. 

5.4.1 Command Processing 

The command processing algorithm Is Initiated by the executive when- 
ever a command Is transmitted to the load center controller (LCC) by the 
EPS controller. The structured design of the command processing algorltiwj 
Is shown In Figure 5-7 (see Appendix A for Instructions on how to read the 
diagram). The Incoming message Is stored In an Input buffer called INBUF. 

A message Is sent to the LCC cathode ray tube (CRT) terminal Indicating 
that the LCC has received a command. The message reads “COMMAND HAS BEEN 
RECEIVED FROM EPS." The message Is then transferred from the Input buffer 
to the message buffer (called MESBUF). The message Is then examined to 
determine what type of conmand was sent from the EPS controller. Four 
types of commands are recognized by the LCC. These commands are load 
on/off switch cmnmands, EPS data requests, EPS Initialization requests, and 
circuit breaker programmable limit commands. The camand formats are shown 
In Table 5-3. The Incoming ccxnmand Is examined to determine which type of 
command has been sent from the EPS. If the command Is not recognized In 
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the command type table, the command is considered to be in error and an 
error message is sent to the EPS controller. Also a message is sent to the 
LCC cathode ray tube (CRT) which reads "CMO INVALID DATA HAS BEEN SENT TO 
THE EPS." The message formats from the LCC to the EPS are shown in Table 
5-4. Each of the four command types are discussed in the following 
sections. 

5. 4. 1.1 Load On/Off Switch Commands 

The load on/off switch command algorithm issues the set and reset 
commands to the load bus circuit breakers in the power distribution net- 
work. Initially, the incoming command is checked to verify that the load 
bus number and the switch number are correct. If either is incorrect, an 
error message is placed in an output buffer and an error message is sent to 
the EPS controller (the error message is actually sent by the executive 
software). Also, a message is sent to the LCC CRT which reads "DATA HAS 
BEEN SENT TO THE EPS" and the error type is displayed on the LCC CRT. 

If the incoming command is correct, then the switch on/off command is 
implemented. Initially the load bus number is read from the message buffer 
and its associated switch status is identified. If any of the switches are 
closed, a reset command is issued, which disconnects all power to the load 
bus. This procedure prevents two power channels from being tied together.* 
After the switch reset commands have been issued, the switch status is 
again verified. At this time, the switch number is read from the message 
buffer and the desired set command is issued. The switch status is again 
verified after this command is issued. The switch status information is 
placed in the output buffer and the verification data is transmitted to the 
EPS controller. Messages are sent to the LCC CRT that say "DATA SENT TO 
EPS" and "ONE EPS CMD EXECUTED." 


* 

This procedure produces break before make switching. For special loads 
requiring uninterrupted power, the procedure may be reversed to produce 
make before break switching, but this requires reverse current prevention 
(diodes) in the switches to prevent interconnecting two power channels. 
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5. 4. 1.2 EPS Data Request 

An EPS data request command Is sent whenever the EPS controller 
requires data from the load center. Data requests for load voltage, switch 
current, switch status, channel current, and circuit breaker trip point 
levels are Issued. The Incoming data request Is read and the requested 
data type Is verified. If the data request Is correct the data is trans- 
ferred to the output buffer and the executive software will send the data 
to the EPS control ;<*r. If the data request Is Incorrect, an error iressage 
is sent to the EPS controller and a message Is displayed on the LCC CRT 
that states “DATA NOT RECOGNIZED.- Also, “DATA SENT TO EPS- Is displayed 
on the LCC CRT terminal. 

5.4. 1.3 EPS Initialization Request 

The EPS Initial Uatl on request Is Issued during any start-up period 
after a power Ow'tage. The Initialization request clears all buffers and 
tables and Input/output switch command ports. After the Initialization 
request has been Implemented, a message Is sent to the EPS controller. 

5. 4. 1.4 Circuit Breaker Programmable Limits 

The circuit breaker programmable limits commands are Issued when the 
trip points on the load bus circuit breakers need to be adjusted. The 
structured design of this algorithm will generally follow that of the other 
command algorltlms. Initially, the Incoming command will be verified. If 
an Incorrect connand 1$ detected, a message will be sent to the EPS con- 
troller and a message will be displayed on the LCC CRT. If a. correct 
command Is detected, then the command will be Implemented and a message 
will be displayed on the LCC CRT. 

5.4.2 Switch and Load Bus >ton1tor1nq 

The switch and load bus monitoring algorithm consists of the monitor 
algorithm and the fault Interrogation algorithm. The monitor algoritimi 
collects and assembles the power distribution network telmnetry and status 
data, and the fault Interrogation algorithm analyzes the data to determine 
If failures have occurred In the power distribution network. These algo- 
rithms are described below. 
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5. 4. 2.1 Monitor Algorithm 

The monitor algorithm Is a routine process that Is activated 
periodically by the LCC executive software. The structured design of the 
monitor algorithm Is shown In Figure 5-8. (See Appendix A for Instructions 
on how to read the diagram.) Five types of distribution network data are 
monitored: load voltages, channel currents, switch currents, switch sta- 
tus, and circuit breaker trip-point limits. The current and voltage moni- 
toring procedures are generally alike. The address of the Input port to be 
monitored Is read from a table and the port Is activated. An analog-to- 
dlgltal converter located In the load center controller Is activated and 
sends an end-of-conversi on (EOC) signal when It Is finished. The algorithm 
verifies the EOC signal. If the EOC signal Is found, the telemetry data Is 
stored In a table. If the EOC signal Is not found, an error message Is 
placed In the LCC output buffer and a “DATA SENT TO EPS" message Is dis- 
played on the LCC CRT. Also, an error message Is displayed on the LCC CRT 
that states "AOC FAILED TO RETURN E0C.“ 

The switch status monitor algorltivn uses a status byte to record the 
switch status. Initially, xhe status byte Is set to zero. Then the switch 
status Is read through the appropriate input port. If the switch Is 
closed, a one Is placed In the appropriate bit In the status byte. If the 
switch Is open, the status byte remains at zero. 

The circuit breaker trip-point limits have not been programmed at this 

time. 


5. 4. 2. 2 Fault Interrogation Algorlt^wi 

The fault Interrogation algorithm Interrogates the status of the 
switchgear and the electrical parameters of the respective load buses (or 
terminals) to determine compliance with the last received command or to 
Identify the failure mode. The last switch command, the present switch 
status, and the load current and voltage are monitored, and the data 
stored. This data Is ccxnpared to the tabulated set of conceivable circum- 
stances (Table 5-5). A status condition Is generated (Table 5-5, Column 
5), and the related message Is sent to the EPS controller. If a ^allure Is 
Indicated (Fault Types 1 through 12), the load priority table applicable to 
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the bus assignment algorithm Is modified to Indicate the new constraint on 
the bus assignment options of that load bus/termlnal . 

Two significant assumptions are made In developing the status table 
and the resulting failure conditions and EPS controller messages. First, 
data processing and storage failures are neglected. A redundancy study Is 
required to define the appropriate accommodation approaches for such fall- 
ures. Second, only a single component failure Is considered. Concurrent 
multiple failures significantly expand the status table. However, the 
corrective action taken after the Initial failure, particularly a switch 
failure, usually preempts the effects of further failures. Hence, this 
approach Is adequate, but the final algorithm must preclude mlsoperation 
with multiple failures. A simple memory approach that retains the fact of 
a switch failure regardless of subsequent failures will be considered. 

Loads are distributed throughout the power subsystem distribution 
network, but their associated switchgear Is geographically grouped into 
load centers for control purposes. Each load center controller Implements 
the switch commands and monitors the resulting performance of the commanded 
distribution switchgear. Hence, each load center controller Incorporates 
this algorithm and executes It Independently of other controllers. 

5.4.3 Load Center Management Processing Requirements 

The load center management algorithms were analyzed to determine the 
computer processing requirements in terms of the number of instructions per 
second that are needed to perform the algorithms. This analysis required 
determining the number of times per minute that the algorithm must be 
repeated and the total number of programming Instructions required to 
define the algorithm. This analysis Is simmarlzed In Table 5-6. 

A repeat time of one sample every 2 seconds was selected for both load 
center management algorithms. This time was based on an engineering judg- 
ment of the time that should be required to report or to execute a change 
In the state of the electrical power subsystem. For Instance, during the 
load bus assignments procedure, a large number of switch on/off commands 
are Issued to and executed by the load center controller. Each ccxnmand Is 
verified, switch status Is monitored, and a verification signal Is sent 
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Table 5-6. Load Center Managemerit Processing Requirements 


Functions 

— 

Instructions 

per 

Function 

Repetition 

Interval 

(sec) 

" ' — " 1 

Controller 

Instruction 

Rate 

(instr/sec) 

System* 

Instruction 

Rate 

(instr/sec) 

Switch and 
load monitoring 
and fault 
interrogation 

17,000 

2 

8,500 

85,000 

Load on/off com- 
mand processing 

2,600 

2 

1,300 

13,000 




9,800 

98,000 


Ten controllers in 250 kW system. 

back to the EPS controller. This process must be performed rapidly in 
order for the controllers to perform other tasks. 


The nimiber of instructions reqrlred to perform the algorithm was 
calculated based on past experience in programming similar algorithms for 
spacecraft applications. 

5.5 EPS MANAGEMENT ALGORITHMS 

The EPS management algorithms provide the processes and procedures for 
the overall power subsystem level functions. The major EPS management 
algorithms are energy planning and allocation, load bus assignments, and 
power subsystem state of health. These algorithms are described in the 
following sections. 

5.5.1 Energy Planning and Allocation 

The energy planning algorithm provides the comprehensive load manage- 
ment to assure adequate power and energy margins for each power channel. 
This energy management function includes the analysis and planning to uti- 
lize effectively the full capabilities of the electrical power sources 
(solar array segments anu batteries) and to enhance the life of the bat- 
teries. These objectives are accomplished by allocating judicious loading 
to each power source channel in order to attain balanced (or otherwise 
planned) operation of normal batteries and lighter loading of degraded 
batteries. 
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The energy planning algorithm utilizes data from the battery charge 
control, and battery state-of -health, solar array status, and power sub- 
system state-of-health algorithms. This data is transmitted from the 
power source and load center controllers to the EPS controller and stored 
in local memory for ready access. 

The energy planning algorithm (Figure 5-9) has two major branches: 
one for sunlight operation and one for eclipse operation. During eclipse 
the state of charge of each battery is calculated, the depth of discharge 
at the end of eclipse projected, and the channel -to-channel imbalance 
estimated based on projected battery depth of discharge. If the imbalance 
is too great, load reassignment is requested of the bus assignment algo- 
rithm based upon the desired nev< load levels calculated by the energy 
planning algorithm for each channel. 

In some circumstances the aggregate load may project a system depth of 
discharge exceeding the nominal operational limit (e.g., 33 percent). The 
spacecraft control authority (computer and ground) is then notified 
requesting a reduction in load. However, this overload is supported with- 
out restraint until a second, more severe system depth-of -discharge limit 
is projected to be exceeded at the end of eclipse (e.g., 50 percent) unless 
a load reallocation command is received. With this overloao condition, the 
spacecraft control authority is notified o^ this second phase, and load 
buses of low priority are deactivated (shut down) to the extent available, 
or until the aggregate load projects an acceptable system depth of dis- 
charge at the end of eclipse (e.g., <33 percent). With this change in 
loads, the bus assignments are recomputed by the bus assignment algorithm. 

Pricrity constraints may preclude significant unloading in this second 
phase. Should a third level of system depth of discharge actually be 
exceeded (e.g., 65 percent), an emergency notice is sent to the spacecraft 
control authority, and load buses are disabled in reverse order of pri- 
ority, but in direct order of load size within a priority category, until 
an acceptable system load level is attained. This load level, if continued 
to the end of eclipse and added to the existing system depth of discharge, 
must not exceed an acceptable one-time battery depth-of-discharge utiliza- 
tion (e.g., 80 percent). Again, bus assignments are recomputed by the bus 
assignment algorithm. In addition, one or two subsequent sunlight periods 
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Figure 5-y. Energy Planning Algorithm Flow Diagram 
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with reduced load may be required to fully recharge the batteries after 
such an incident. 

Terrestrial modificatioi of these results is possible by programming a 
new set of limits for system depth of discharge; for example, 40, 55, 70 
instead of the suggested 33, 50, 65 examples. The major objective is to 
support loads, even though temporarily excessive, until the last possible 
manent before curtailment of operation is necessary for survival. Such 
curtailment is abnormal, and only due to extreme overloads or an unusual 
degree of degradation. 

During sunlight operation, the energy planning algorithm calculates 
the available system energy for battery charging and projects the state of 
charge at the beginning of the next eclipse. If full recharge is attain- 
able, channel load balancing based upon existing state of charge is calcu- 
lated. Excessive imbalance, leading to deficient charging for one or more 
batteries, generates a request of the bus assignment algorithm to reassign 
loads based upon the newly calculated desired channel loadings. 

A projection of insufficient energy for full system recharge leads to 
two alternatives: (1) continue operation without assurance of attaining 

full recharge or (2) enter a mandatory load reduction routine to make 
sufficient energy available to fully recharge the batteries. Mandatory 
load reduction occurs when the system state of charge is projected to fall 
below a safe value (e.g., 50 percent), or if full recharge has not been 
achieved recently (e.g., over 15 eclipse cycles, approximately one day). 

The spacecraft control authority is notified of the pending action, and 
sufficient load buses are deactivated (shut down) with appropriate priority 
and load value considerations until full recharge capability is projected. 

Operational load support is continued if the system state of charge is 
above the safe value (e.g., 50 percent) and the system has been recently 
fully charged (e.g., less than 16 eclipses, or less than a day). When the 
spacecraft control authority is requested to reduce loads, the desired 
channel load levels are recalculated by the energy planning algorithm, and 
the load buses are reassigned by the bus assignment algorithm to attain a 
reasonably uniform state of charge (or other preplanned distrioution) on 
the batteries. 
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Terrestrial modification of these results is possible by programming a 
new set of limits; for example 60 percent and 4 and 5 eclipses instead of 
50 percent and 15 and 16 eclipses. Again, the major objective is to sup- 
port loads, even though temporarily excessive, as long as possible before 
curtailment of operation. 

5.5.2 Load Bus Assignments 

The configuration of the distribution system (load center switch 
selections) is dependent upon a large and complex interaction of parameters 
(Figure 5-10). The central control algorithm for definition of the distri- 
bution system configuration is the load bus assignment algoritlvn. The load 
bus assignment algorithm is supported by other algorithms and data tables: 
energy planning algorithm, load command processing, switch monitor algo- 
rithm, state-of -health algorithm, and various load (or load bus) data 
tables, including switch options, initial load currents, latest load cur- 
rents, switch failures, load priorities, and power quality desires, etc. 

The load bus assignment algorithm, as the name implies, provides a 
logical assignment of loads (or load buses) to the power channels (main 
buses) and as such defines the distribution configuration of the electrical 
power system. The output of this algorithm is a table of distribution 
switch closure assignments that identify the computer selected distribution 
configuration. To define the desirable distribution configuration, the 
load bus assignment algorithm evaluates the desired power channel loading, 
the existing channel loading, existing load currents, expected currents for 
new loads, the specified operational profile, and the distribution switch- 
ing options. The desired channel loading data comes from the energy plan- 
ning algorithm. The expected load currents and the load-to-channel switch- 
ing options are provided by the load priority table. The desired load 
implementation (load operational pattern) is provided by the spacecraft 
controller or from terrestrial commands. 

5.5.2. 1 Load Bus Assignments Methodology 

One method of selecting the best configuration for the distribution 
system is to analyze all of the possible configurations, determine the 
mismatch of each channel for each configuration, and select the one con- 
figuation which minimizes the imbalance among the channels. However, this 
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approach is impractical. The total number of possible distribution 
configurations is given by k” where n is the nimiber of loads or load buses 
and k is the number of possible channel connections for each load (or load 
bus). On a 250-kilowatt power system, over 200 load buses are anticipated 
with a minimun of two channel connections per load bus. A total of 1.6 x 
10®® distribution configurations would need evaluation. With an extremely 
optimistic computer speed where one configuration is evaluated every mic'*o- 
second, this solution approach would require 5 x 10 years to compute! 

A practical approach-to load assignment is attained by ranking the 
load (load buses) by their respective power (current) and then segregating 
this load list into "g" groups of "N" loads according to their relative 
power, largest loads in the first group, smallest loads in group “g." All 
the distribution configurations for the first load group (highest power) 
are computer evaluated, and the configuration for minimum channel imbalance 
is selected. The channel loading results for this first load group are 
subtracted frcxn the desired channel loading, and the results become the 
desired channel loading for the second group analysis. This procedure is 
repeated for each successively lower powered load group until all groups 
have been evaluated. 

This approach significantly reduces the number of configurations for 
evaluation when small group sizings are employed. The total number of 
configurations evaluated employing this approach is: 

® Ni 

S K. ^ » niBtber of configurations 
i»l ’ 


where 

g » the number of load groups 

■ the number of load buses in a given group 

■ the number of channel connection options available for each 
load bus in the group 

For a group sizing equal to 10 load buses (N « 10), the total number of 
groups becomes 20 (g ■ 20) for the 250-kilowatt system with 200 load buses. 
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The total number of configurations evaluated Is then reduced to 20.4 x 10^ 
and these can easily be evaluated in several minutes. 

The result of this grouped approach may not consider the specific 
configuration that produces absolute minimum unbalance. However, within 
the constraint of the available load increments, a very low unbalance and 
readily acceptable configuration is attained with reasonable computation 
time. Hence, a cost-effective solution j_s attained, though not necessarily 
the absolute minimum unbalance that it might be possible to attain. 

5. 5. 2. 2 Load Bus Assignment Priorities and Constraints 

The load bus assignment algorithm must accommodate certain operational 
priorities and constraints imposed by the spacecraft system. Examples of 
such criteria that would affect the assignment of load buses to channels 
are listed below: 

a) In general, the load bus assignment algorithm will balance the 
load on each power channel (see Trade Studies and Analyses, 
Section 8). However, in certain cases when power sources are 
degraded, the loads will be unbalanced based on a specified 
load ratio. 

b) One or more “quiet'' channels may be designated for sensitive 
loads 

c) One or more channels may be designated for particularly noisy 
or pulsed power loads 

d) Limitations may be applied to the switching of loads such as 
"make before break" to assure continuous power availability, or 
some loads may be designated as "undesirable" to switch 

e) Load priorities may be established for normal, emergency, 
start-up, and other specific operating conditions such as 
limited power availability 

f) Criteria for rebalancing the channel loads must be established 
based on a specified sensitivity to the amount of allowable 
unbalance per channel. Also, sensitivity to pulsed loads must 
be established when determining the rebalance criteria. 

All of these criteria (and/or others) may be employed in defining the 
assignment of loads to power channels. 
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5. 5. 2. 3 Structured Design of the Load Bus 
Assignments Demonstration AlgorltNn 

A demonstration algorithm was developed for the load bus assignments 
function In order to verify the feasibility of the above-mentioned computa- 
tional concepts. A power distribution network configuration was assumed, 
as shown In Figure 5-11. Load priority tables were established for load 
bus current, channel connections, switch positions, and system load priori- 
ties, as described In the power subsystem state-of -health algorithm. Sec- 
tion 5.5.3. (The load priority tables are a part of the power subsystem 
state-of-health algorithm.) A generalized algorittm) was developed and a 
specific example was performed to verify functional operation. The data 
that was entered Into the load priority tables Is shown In Table 5-7. Each 
load bus was assigned a relative bus number which Is used by the computer 
to Identify the bus. Load bus currents were arbitrarily assigned as shown 
In the load bus current file (LC-LPT). The channel connections reflect the 
configuration of Figure 5-11. The switch positions are shown in the Ini- 
tial condition that Is assumed when the configuration selection routine is 
performed. (A one Indicates that the switch Is closed and a zero indicates 
that the switch 1$ open.) All the loads were assumed to be switchable 
(Priority 3) for this demonstration algorltimi. The algorithm assumes that 
the loads will be balanced evenly across the three power channels. In 
other words, the desired channel loading (DDL) Is the sum of the load 
currents divided by three. (Later on, when a complete power management 
system Is operating, the desired channel loading will be determined by the 
energy planning process.) 

This demonstration algorithm is a building block to an operationally 
viable algorithm. The demonstration algorithm requires expansion to Incor- 
porate further operational priorities and power quality constraints and to 
receive variable channel loading Inputs from the energy planning algoritNn. 
The expansion of this basic demonstration algorithm Is projected for a 
future algorlttin development contract. 

A structured diagram of the load bus assignments algorithm Is shown In 
Figures 5-12 and 5-13. (An explanation of how to read the structured dia- 
gram is presented In Appendix A.) Seven main modules are used to describe 
the algorltiwi. To begin, any new load buses which need to be activated die 
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Table 5-7. Load Priority Table Data for Load Bus Assignment 
Demonstration Algorithm 


Load 

Bus 

No. 

Relative 

Bus 

No. 

Load 

Bus 

Current 

(amps) 

(LC-LPT) 

Channel 

Connections 

(LHC-LPT) 

§w1tch 

Positions 

(SW-LPT) 


SW 

1 

SW 

2 

SW 

3 


1 SW 2 

SW 3 

Norm Emer 


1 

10 

Ch 

1 

Ch 

2 

Ch 

3 

1 

0 

0 

3 

3 


2 

15 

Ch 

1 

Ch 

2 

0 


1 

0 

0 

3 

* 3 


3 

15 

Ch 

1 

Ch 

3 

0 


1 

0 

0 

3 

3 

1-4 

4 

15 

Ch 

2 

Ch 

3 
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1 

0 

0 

3 

3 
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5 

7.5 

Ch 

1 

Ch 

2 

0 


1 

0 

0 

3 
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1 

Ch 

3 

0 


1 

• 0 

0 

3 

3 

1-7 

7 

7.5 

Ch 

2 

Ch 

3 

0 


1 

0 

0 

3 

3 

1-8 

8 

3.75 

Ch 

1 

Ch 

2 

0 


1 

0 

0 

3 

3 

1-9 

9 

3.75 

Ch 

1 

Ch 

3 

0 


1 

0 

0 

3 

3 

1-10 

10 

3.75 

Ch 

2 

Ch 

3 
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1 

0 

0 

3 

3 
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10 
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Ch 

2 

Ch 
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1 

0 
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Ch 

1 

Ch 
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0 

0 

3 

3 

2-9 
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Ch 
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selectively connected to an appropriate channel, avoiding possible 
overloading of any of the power channels; then the existing distribution 
system configuration is evaluated to determine the channel loading con- 
ditions. Using this data the desired channel loading (DCL) for the switch- 
able loads (and the semiswitchable loads in some cases) is calculated. The 
configuration options are then evaluated to determine the best configura- 
tion. If there are overloading conditions which cannot be resolved by 
reconfiguration, some load buses will be selectively disconnected using 
their emergency load bus priorities. The switching sequence is then set 
up, the commands are transmitted and the resulting configuration is 
displayed on the electrical power subsystem controller terminal. Each of 
these functions are discussed in subsequent sections. 

5. 5. 2.3.1 Connect New Load Buses 

This module will check to see if any new load buses are to be powered 
up. If there are, it will determine to which channel the load bus is to 
connect. This process will be supported by the power subsystem state-of- 
health algoritNn which will expand its load priority table to account for 
the new load buses (see Section 5.5.3). Once it has been determined that 
new loads are to be serviced by looking at the initializing status in the 
load priority table, the distribution buses are powered up in the order 
given by the start-up priorities. The start-up priorities are used to 
assure that any dependence among the loads are accounted for (e.g., the 
dependence of some experiments on experiment support equipment). The 
proposed priority method will allow a group of load buses to be turned on 
and tested before further load huses'~are initialized. This is handled by 
identifying a group of load buses by a common start-up priority number. 
Starting with the lowest priority, the loads in the group a.*e turned on one 
at a time, sequentially as they are listed in the load priority table. 

Then the load bus testing which is required is implemented before the next 
group of load buses is turned on. The channel connection chosen for each 
load bus is based on the maximum power margin for the connections available 
to the loaJ. The power margin in this context refers to th^ difference 
between the present channel loading and the maximum load limit. Once all 
of the new load buses are connected, the energy planning and allocation is 
reevaluated with the new loads on the system. 
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5. 5. 2. 3. 2 Evaluate the Present Distribution System Configuration 

The load assignment function sets up the configuration-evaluation 
(CONF-EVAL) file which stores the channel currents for each channel. 

The channel currents are subdivided, and categorized by their channel 
number and the system load priorities as described. The CONF-EVAL file is 
set up as shown in Figure 5-14 with the total load current for each channel 
for each priority of 0, 1, 2, 3, and 4 stored independently. Note that all 
the channel currents are stored as double precision words (32 bits). The 
total channel load current is stored in the eleventh and twelfth 16-bit 
word locations allotted for each channel. 

The FORTH word defined to assemble this data is EVAL-CONF. When EVAL- 
CONF is invoked the CONF-EVAL file is first initialized to zero. Then 
taking one bus at a time the load current is read frtwi the LC-LPT file, its 
classification (and the channel which is supplying it) is determined, and 
the current is summed to the appropriate current in the CONF-EVAL file. 

Once all the load bus currents are sunnned into their designated memory 
locations, the currents supplied by each channel are totaled by summing the 
currents of the five classifications and this value is stored. 

The data in the CONF-EVAL file in Figure 5-14 reflects the load cur- 
rents and switch positions of Figure 5-17. Since we have assumed that all 
the load buses are Priority 3, the total channel current coincides with the 
Priority 3 channel current. (This configuration is clearly not the desired 
one, but illustrates the algoritim.) 

5.5.2. 3.3 Determine the Desired Channel Loads for the 
Switchable (and Semiswitchable) Load Buses 

The load assignments algorithm calculates the desired channel loading 
(DCL) for each of the channels for the switchable loads (i.e.. Priority 3). 
The algorithm was developed such that it will also calculate the desired 

channel loading for both the switchable and semiswitchable loads, i.e.. 
Priorities 2 and 3, if it is desired. (This would require reassignment of 
some of the load buses to Priority 2 in the system load priorities table.) 
Hypothetically, the request for priority 2 and 3 loads would be made if no 
satisfactory loading conditions resulted from the configurations evaluated 
for Priority 3 loads only. 
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The FORTH word defined to calculate the desired channel loading for 
the Priority 3 loads is 0CL3. The inputs to the routine are the OCLs which 
are the output of the energy planning and allocation. The resulting output 
of 0CL3 is the channel current which should be made up of the Priority 3 
loads. The DCLs resulting from the energy planning and allocation algo- 
rithm give the total load current for each channel which is made up of all 
five load priorities. Therefore, to obtain DCL3, the load currents for 
Priorities 0, 1, 2, and 4 must be subtracted from the OCL for each channel. 
Since these current values are stored in the CONF-EVAL file along with the 
Priority 3 currents and the total channel current the DCL3 can most quickly 
be determined for each channel by the following calculation: 

0CL3^ » OCL^ - Total Channel Load^ + Priority 3 Channel Load. 

where i = one to three channels for the demonstration algorithm 

If the resulting DCL3 is less than zero a fault message will be generated. 
This fault message has not been programmed at this time. 

Continuing the example, since the Priority 3 load buses are the total 
load on each channel, 0CL3 » OCL for each channel. As previously dis- 
cussed, the desired channel loading is equal to the sum of all the loads 
divided by the number of channels (three). Therefore, 0CL3 = 59.2 amperes 
for each channel. 

5, 5. 2. 3, 4 Select Configuration Option (SLCT-TOTAL-CNF) 

This process sorts the load bus currents according to magnitude and 
then evaluates the configuration options so that the selection of the best 
configurations is made. The process sets up a new set of tables, as shown 
in Table 5-8, that are constructed from the load priority tables of 
Table 5-7. 

5. 5. 2. 3. 4.1 Set Up Current Table for Load Bus Assignments (SETUP-CUR-LA) 

This process sets up a load bus current table (CUR-LA) along with the 
associated relative bus number (B-LA) table by sorting through all of the 
load bus currents one at a time and then arranging the currents for the 
switchable (and semiswitchable, if desired) load buses in descending order 
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Table 5-8. Configuration Option Selection Load Bus Assignment Table 


Group 

No. 

Load Bus 

Current 

(CUR-LA) 

Relative 
Bus No. 
(B-LA) 

Load 

Bus 

No. 

Switch 

Configuration 

(SWT) 

Channel 
Connect! on 
(CH-CON) 

Best Switch 
Configuration 
(BSWT) 


wmm 

2 

1-2 

0 

1 

0 



3 

1-3 

0 

1 

0 

1 

15 

4 

1-4 

0 

2 

0 


15 

12 

2-2 

0 

1 

0 


15 

13 

2-3 

0 

1 

0 


m 

14 

2-4 

0 

2 

0 



1 

1-1 

0 

1 

0 

2 

10 

11 

2-1 

0 

1 

0 



5 

1-5 

0 

1 

0 



6 

1-6 

0 

1 

0 


7.5 

mm 

1-7 

0 

2 

0 


7.5 


2-5 

0 

1 

0 

3 

7.5 


2-6 

0 

1 

0 


7.5 

17 

2-7 

0 

2 

0 


3.75 

8 

1-8 

0 

1 

0 

4 

fm 

9 

10 

18 

19 

20 

1- 9 
1-10 

2- 8 
2-9 
2-10 

0 

0 

0 

0 

0 

1 

2 

1 

1 

2 

0 

0 

0 

0 

0 


starting with the largest current magnitude first. The relative bus number 
is stored “adjacent" to its respective current for accounting purposes. 

The data in the tables of Table 5-8 show the resulting ordered currents for 
our specific example. The software modules which support this process are 
shown in Figure 5-12. 

5. 5. 2. 3. 4. 2 Select Group Configurations Independently (SLCT-GRP-CNF) 

The process of stepping through each of the configurations and 
evaluating that configuration for the best balanced condition is programmed 
by this module. The load buses are evaluated in groups of 5, as shown in 
Table 5-8, starting with the group that has the largest current magnitudes. 
There are two main levels of software modules for this selection process. 
The first level (Level 4 of Figure 5-12) sets up the parameters for the 
group and then the second level (Level 5 of Figure 5-12) steps through each 
configuraton within the group. 
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The step-by-step procedure for performing this algorithm is described 
as follows: 

1) First, a file called PBOCL-MM (previous best desired channel 
loading mismatch) is initialized with the 0CL3 data derived 
from Section 5. 5. 2. 3. 3 for each channel (DCL3 » 59.2 amperes 
for each channel). 

2) Next, the switch configurations are set to their initial posi- 
tions. The initial position for each load bus corresponds to 
Switch 1 being on, as illustrated by Table 5-7. This step also 
initializes a base three counter that is used to step through 
each of the possible combinations for the first group of five 
loads, as shown in Table 5-8. A base three counter is used 
since two of the load buses have three switches. The switch 
configuration is stored in a file called (SWT), as shown in 
Table 5-8. 

3) After the switch positions are initialized, the channel connec- 
tions are updated from the channel connection file in the load 
priority table (CHC-LPT), shown in Table 5-7. The updated 
channel connections are stored in a temporary file called 
(CH-CON), as shown in Table 5-8. Since most of the load buses 
do not have three switches, it is possible for the base three 
counter to obtain states that are not realizable. This condi- 
tion is verified during this step when the channel connections 
are updated. If a nonreal izable state is detected, the counter 
is incremented to the next state and the channel connection 
update procedure is again performed. The base three counter 
operation is illustrated in Figure 5-15 for the first group of 
load buses in Table 5-8. 

4) Once the channel connections have been updated for the first 
group of loaa buses, then the load current for each channel of 
the first group is summed and subtracted from the value in the 
PBDCL-tti file for each channel. (Initially this number is DCL3 
as described in Step 1.) The results are the desired channel 
loading mismatches and tnese three values are stored in a file 
called DCL-MM (desired channel loading mismatch). 

5) The DCL-MM numbe. s are then compared with each other to deter- 
mine which one is the maximum. The maximum DCL-MM is stored in 
a temporary file called MAX-MMT. If the maximum DCL-MM is less 
than the previously recorded maximum DCL-MM, then the new maxi- 
mum DCL-MM will be recorded in a permanent file called MAX -MM. 
(Since this is the first time through in this example, the 
value will automatically be recorded in the MAX-MM file.) If a 
smaller MAX-MM is obtained, then this configuration represents 
the best configuration that has been evaluated so far and the 
channel loading recorded in DCL-MM is transferred to a file 
called BDCL-MM (best desired channel loading for minimum mis- 
match) and the switch configuration is recorded in a file 
called BSWT (best switch configuration). The overall process 
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is illustrated in Figure 5-16 for the first group loads in 
Table 5-8 with the initial switch positions. 

6) The switch positions are now incremented by means of the base 
three counter, the channel connections are again updated, the 
realizable state is verified, and Steps 4 and 5 are repeated. 
This entire process is repeated until all the possible combina- 
tions for the first group load buses have been evaluated for 
the minimum mismatch. 

7} After the first group loads have been completely evaluated, the 
best desired channel loading that can be obtained with the 
first group load buses is stored in 6DCL-MM and the corres- 
ponding best first group load bus switch configuration is 
stored in BSWT. At this time, the PBDCL-MM file is updated 
with the B0CL-W1 data, which forms the starting point for the 
second group load bus evaluation. 

8) The entire process is now repeated for following group load 
buses until the best configuration is obtained. 

5. 5. 2. 3. 5 Disconnect Load Buses for Overloaded Channels 


For the case where the best configuration option results with one or 
more of the power channels overloaded, the software imjst identify and 
alleviate this condition. The disconnect load buses software will address 
this issue by surveying the overloaded channels to determine if there are 
disconnect controllable load buses (i.e.. Priority 4 in the system load 
priority of the load priority table, SLP-LPT) which, if disconnected, would 
remove the overloaded condition. If no satisfactory solution is found with 
the normal priority settings, the mode of operation would be switched to 
the emergency condition. Then the analysis which is necessary to select 
the load buses for removal would be based on the emergency load priority 
information in the SLP-LPT. Once the overloaded condition is alleviated, 
it may be desirable to reevaluate the configuration options if the result- 
ing maximum mismatch is larger than acceptable. This reevaluation decision 
will be made internal to this module. The software controlling these 
decisions has not been developed to date. 

5. 5. 2. 3. 6 Setup Switching Sequence 

As mentioned earlier in the load assignment methodology section, a 
switching sequence must be selected for the transfer of load buses from 
channel to channel such that overloading of the power channels is avoided. 
The setup switching sequence module will set up the sequence order that 
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commands be sent, order command verification, and reschedule load 
assignments If a faulty switch operation Is reported. The presently pro- 
gramnwd approach Implements all of the above-mentioned processes except for 
the switching sequence analysis. The commands are processed one at a time 
In the order that the load buses were arranged for the load assignment 
group classification, starting with the load bus with the largest current 
first. 

5. 5. 2. 3. 7 Output Load Bus Assignments Results (LA-RESULTS) 

This process outputs the results of the load assignments analysis In 
two parts. The first part Is the load bus data which Is displayed In 
tabular form with the following headings: 

a) Load Bus Number 

b) Switch Number of "ON" Switch 

c) Channel Connection 

d) Load Bus Current. 

The second part Is displayed by hitting the "return** key on the 
keyboard/video display unit. This part Is made up of the summary data for 
the channels, and Is also displayed In tabular form with the following 
headings: 

a) Channel Number 

b) Desired Channel Loading 

c) Resulting Channel Loading 

d) Resulting Channel Mismatch. 

The total number of configurations evaluated Is also displayed along 
with this data. 

The hlerarchlal structured design of this software module Is Illustra- 
ted In Figure 5-13. The design Is mostly self-explanatory, with the pro- 
cess flowing from left to right. The first FORTH word "RESET-TCONF-EVAL" 
resets the TCONF-EVAL table to zeros. This table Is used to total the 
channel loading as the load bus currents are displayed. The decision box 
In the LB-OATA module decides whether the load bus data has been updated by 
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the configuration selected or if it Is the same as before the analysis was 
done. Each of the headings In the modules Is the FORTH word defined to do 
the processing. 

5. 5, 2. 4 Load Bus Assiqrewent Solution for Specific Example 

The load bus assignment demonstration algorithm as described 1n Sec- 
tion 5. 5.2.3 was run on the electrical power subsystem controller for the 
specific example of Figure 5-11 and Table 5-7. The results of this solu- 
tion are shown In Table 5-9. The results show that the channels were 
balanced to within 2.9 percent of the desired load balance which would be 
well within the desired balancing accuracy of an actual system. t | 

Table 5-9. Load Bus Assigmmnt Solution for Specific Example 


Load Bus 

Switch On 

Channel 

Connection 

Load Current 
(amperes) 

1-1 

2 


2 

10 

1-2 

1 


3 

15 

1-3 

2 


1 

15 

1-4 

1 


2 

15 

1-5 

2 


2 

7.5 

1-6 

2 


1 

7.5 

1-7 

2 


1 

7.5 

1-8 

2 


2 

3.75 

1-9 

2 


1 

3.75 

1-10 

2 


1 

3.75 

2-1 

2 


2 

10 

2-2 

1 


3 

15 

2-3 

1 


3 

15 

2-4 

2 


1 

15 

2-5 

1 


3 

7.5 

2-6 

2 


1 

7.5 

2-7 

1 


2 

7.5 

2-8 

1 


3 

3.75 

2-9 

1 


3 

3.75 

2-10 

1 


2 

3.75 

Channel 

Nimiber 

Desired 

Loading 

(amperes) 

Resulting 

Loading 

(amperes) 

Resulting Mismatch 
(amperes) 

1 

2 

3 

59.2 

59.2 

59.2 

60 

57 

60 

.5 

-0.8 (-1.3%) 
1.7 (2.9%) 
-0.8 (-1.3%) 
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A second example was constructed by changing the load current on load 
Buses 1-1, 1-2, and 1-10 to 12.9, 13.7, and 5.3 amperes, respectively. The 
load bus assignments algorithm balanced these loads to within ^0.3 percent, 
as Illustrated In Table 5-10. 

Table 5-10. Second Example of Load Bus Assignments Algorithm 


Load Bus 

Switch On 

Channel 

Connection 

Load Current 
(amperes) 

1-1 

3 

1 

12.9 

1-2 

2 

2 

13.7 

1-3 

2 

1 

15 

1-4 

1 

2 

15 

1-5 

1 

3 

7.5 

1-6 

1 

3 

7.5 

1-7 

2 

1 

7.5 

1-8 

1 

3 

3.75 

1-9 

2 

1 

3.75 

1-10 

1 

2 

5.3 

2-1 

3 

1 

10 

2-2 

1 

3 

15 

2-3 

1 

3 

15 

2-4 

1 

2 

15 

2-5 

1 

3 

7.5 

2-6 

2 

1 

7.5 

2-7 

1 

2 

7.5 

2-8 

1 

3 

3.75 

2-9 

2 

1 

3.75 

2-10 

1 

2 

3.75 

Channel 

Number 

Desired Loading 
(amperes) 

Resulting 

Loading 

(amperes) 

Resulting Mismatch 
(amperes) 

1 

2 

3 

60.2 

60.2 

60.: 

60.4 

60.2 

60 

-0.2 (-0.3%) 
-0- (0%) 

+0.2 (+0.3%) 


These two examples Illustrate that the mathematical procedure for 
balancing the loads Is correct. The algorltNn was capable of balancing 
these loads ver> accurately. However, In general, the balancing accuracy 
wiH depend on the number and magnitudes of the loads which are available 
for switching without system Implied constraints. 
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5.5.3 Power Subsystem State»of -Health 

The power subsystem state-of<hea1th algorithm maintains the overall 
status of the power system by performing the following functions: 

a) Assembles and updates the summary data which determines the 
battery and solar array states of health. 

b) Interprets fault messages from the power subsystem, makes the 
appropriate adjustments In the tables, and takes the necessary 
control action. 

c) Interprets Information requests from the spacecraft controller, 
assembles the requested data, and sends it back to the 
spacecraft controller. 

d) Interprets commands from the spacecraft controller and Issues 
them to the appropriate power subsystem controller. 

e) Assembles and updates load priority tables based or. startup, 
energency and new load conditions, and telemetry and status 
data. 

f) Provides command control for setting and verifying the proper 
circuit breaker current limits. 

The summary data for the battery state of health consists of the 
battery capacities, cell failures, and charge/discharge parameter limits. 
For the solar array state of health, the output power capabilities, string 
failures, and degradation status are included in this summary. Th« load 
priority tables effectively serve as the electrical distribution system 
state-of-health table. The structural design of the load priority tables 
is shown in Figure 5-17. The following load priority table files have been 
set up for the load bus assignment demonstration algorithm: 

a) System Load Priorities for Load Priority Table (SLP-LPT) 

This file stores the priority of each load bus for normal and 
emergency operation. One byte is required for each priority; 
therefore 2 bytes per load are used. 

Priority definitions used: 

0 - no load 

1 - nonswitchable load 

2 - semiswitchable load 
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3 - switchable load 

4 - disconnect control. 

This file must be set on start-up and Is alterable yla space- 
craft controller Interfaces. 

b) Switch Positions for Load Priority Table (SW-LPT) 

This file stores the load bus switch status for each of the 
load buses. One byte Is used for each load bus with each bit 
corresponding to a designated bus switch. (Example; the first 
bit Is for the first switch, the second bit Is for the second 
switch, etc.) A one Is stored for the switch ON and a zero Is 
stored for the switch OFF In the respective bit. 

This file must be set by data transfers requested by the EPSC 
from the LCCs. 

c) Channel Connection for Load Priority Table (CHC-LPT) 

This file stores sequentially the channel connection for each 
switch of each load bus. Each switch has 1 byte allocated and 
each load bus has memory space allocated for three switches. 

The number of the channel which the switch connects the load 
bus to when It Is turned on Is stored In this file. A zero Is 
stored to signify no switch or no channel connection. This Is 
used In the case where less than three switches actually exist 
for a given load. This file must be set on start-up and Is 
alterable via spacecraft controller Interfaces. 

d) Load Bus Current for Load Priority Table (LC-LPT) 

This file stores the actual current values for each of the load 
buses. Each load current Is stored sequentially with one data 
location cell required for each load current. 

5.5.4 EPS Management Processing ’Requirements 

The EPS management algorithms were analyzed to determine the computer 
processing requirements In terms of the number of Instructions/second that 
are needed to perform the algorithms. This analysis required determining 
the number of times per second that the algorithm must be repeated and the 
total nupber of programming Instructions required to define the algorithm. 
This analysis Is summarized in Table 5-11. 

The repeat time for the energy planning and allocation and load bus 
assignments algorithms was based on the 90-minute spacecraft orbit with 
36-m1nute eclipse and 54-minute daylight periods. A repeat time of every 
5 minutes was selected based on an engineering judgment that the energy 
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Table 5-11. Electrical Power Subsystem Management 
Processing Requirements 


Functions 

Instructions 

per 

Function 

Repetition 

Interval 

(sec) 

Controller 

Instruction 

Rate 

(Instr/sec) 

Sy;tem* 

Instruction 

Rate 

(Instr/sec) 

Spacecraft and 
Executive 

8.700 

1 

8,700 

17,400 

Power Subsystem 
State of Health 

103,000 

60 

1,717 

3,433 

Energy Planning 
and Allocation 

8,000 

300 

27 

53 

Load Assignments 

5,400,000 

300 

18,000 

36,000 




28,444 

56,886 


*Two subsystem controllers operating simultaneously; one redundant 

balance of the electrical power subsystem should be calculated six to seven • 
times during each period. This judgment was made based on the fact :hat 
the electrical power subsystem Is a utility-type system In which the load 
profiles are unknown and are constantly changing. Therefore corrective 
action may be required at any time during the orbit to maintain specified 
bus voltage limits. The power subsystem state-of-health algorithm was 
arbitrarily selected to operate once per minute. The executive algorithm 
which schedules the overall tasks for the EPS controller was selected to 
operate once per second. J 

The number of Instructions required to perform an algorithm were cal- 
culated based on past experience In prograinnlng similar algorithms for 
spacecraft applications. 

5.6 EXECUTIVE SOFTWARE 

Executive software was developed for the power management system con- 
trollers based upon the development system Inherent In the selected operat- 
ing system (FORTH). An Interface diagram of the software components Is 
shown In Figure 5-18. A description of the software components Is pre- 
sented In the following sections. 
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BIA 

BIAH 

DMA BUFFER 

INTERRUPTS 

MSGQ 

OS EXEC 

RTCH 

TQ 


BUS INTERFACE ADAPTER 

BUS INTERFACE ADAPTER HANDLER 

DATA STORAGE BETWEEN BIA AND BIAH 

INTERRUPTS BETWEEN BIA AND BIAH 

DATA QUEUES BrrWEEN BIAH AND OS EXECUTIVE 

OPERATING SYSTEW EXECUTIVE LOOP 

REAL-TIME CLOCK HANDLER 

TIMER QUEUE SET BY POWER CONTROL TASK 
PROCESSED BY OS EXECUTIVE 


Figure 5-18. Software System Interface Diagram 
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5.6.1 BIA Handler (BIAH) 

The BIA handler provides the communication link among the power con- 
trollers. When the BIA receives data from the data bus. It stores the data 
received In Its local buffer. The received data Is then verified and the 
data transferred to the DMA buffer. The BIA then Interrupts the BIAH and 
Informs the BIAH that data Is available for processing. Upon receiving the 
Interrupt the BIAH checks the receive/error status; If no error, the 
received data Is then moved to tie system input queue (MSGQ In Figure 5-18) 
for further processing by the operating system (OS) executive. If an error 
Is detected, the BIAH U'-s appropriate error recovery procedures. 

5.6.2 Real-Time Clock Interrupt Handler 

The Real-Time Clock Handler (RTCH) 1ncr«*ments tne counter within the 
timer queue (TQ, Figure 5-18) upon receipt of a hardware clock Interrupt 
(for example, every 10 milliseconds). The timer queue Is a file of task 
Identification words and timer counter values associated with the power 
control tasks. The operating system reads the timer queue counter and the 
task file to determine the next task/routine to be performed. 

5.6.3 Operating System Executive 

The operating system executive operates In a round-robin manner. 

While not serving the RTCH or BIA Interrupts, the operating system execu- 
tive runs through the executive loop looking for work to dispatch. If any 
one of the functions Is dispatched, the program returns to the start of the 
executive loop. If all functions are checked and nothing Is dispatched the 
CPU Idle counter Is Incremented at" the end of the loop. Figure 5-19 Is a 
flow diagram of the executive loop. 

Each executive function Is described In the following subsections. 

a) Process BIAH to Message Queue (MSGQ) 

Data "ecelved from the BIA are queued by the BIAH Into the 
operating system message queue. The operating system processes 
the data In the queue one at a time by activating the corres- 
ponding power control task (type) that Is Identified In the 
queue entry. The following Is a definition of the entry: 

MESSAGE OR COMMAND TYPE - MESSAGE TEXT 
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Figure 5-19. Flow Diagram of Executive Loop 

If any task is dispatched, return is to the start of the 
executive loop. If there is no entry in the queue, the next 
function in the loop is served. 

b) Process Timer Queue (TQ) 

The timer queue entries are examined in sequence until a time- 
out “one" is found. The task Identification for this time-out 
entry is dispatched and the return is to the start of the 
executive loop. If there is no time-out event in the queue, 
the control is passed to the increment idle count process 
(Figure 5-19). 

c) Increment Idle Count Process 


If the executive loop reaches this function then no other func 
tion was ready to run and an idle state is indicated. The 
executive increments the idle counter. This counter can be 
used to quantify the activity within a power controller. 
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6. POWER MANAGEMENT SUBSYSTEM 

A decentralized data processing approach was selected for the power 
management system based on the electrical power subsystem (EPS) algorithms 
that are to be performed and the control hierarchy trade studies and analy- 
ses described In Section 8.2. The components of the power management sub- 
system (PMS) and their relationship to the electrical power subsystem (EPS) 
and the autonomously managed power system (AMPS) are described In the fol- 
lowing sections. 

6.1 FUNCTIONAL DESCRIPTION OF THE ELECTRICAL POWER SUBSYSTEM 

The major components and Interfaces of an EPS with automated power 
management capability are shown In Figure 6-1. As defined for this pro- 
ject, the EPS Is made up of energy storage devices, power generation 
devices, the AMPS, and thermal processing equipment. The energy storage 
devices are nickel -hydrogen batteries and the power generation device con- 
sists of solar array panels. The thermal processing equipment provides the 
means to control and maintain the spacecraft within specified temperature 
limits. The thermal processing system Is a pumped fluid system. The AMPS 
Is described below. 

6.2 FUNCTIONAL DESCRIPTION OF THE AUTONOMOUSLY MANAGED POWER SYSTEM 

The Autonomously Managed Power System (AMPS), Figure 6-1, consists of 
the Power Management Subsystem (PMS) and the devices that distribute, pro- 
cess, and manage the power delivered from the power generation and energy 
storage devices. The building blocks for the power processing, cjndltion- 
Ing, protection, and distribution functions are the energy storage elec- 
tronics, power generation electronics, primary power distribution, power 
conditioning, and secondary power distribution modules. Included In each 
of these modules are the Input/output (I/O) circuits that are part of the 
PMS. The energy storage electronics are responsible for the processing of 
the power flow to and from the energy storage devices so that proper charg- 
ing, discharging, and maintenance can be accomplished. 

Battery reconditioning and cell failure detection circuitry are also 
Included In the energy storage electronics. The function of the power 
generation electronics Is to process the power from the solar array panels. 
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Figure b-l. Autonomously Hanaged Electrical Power System 
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Included In the power generation electronics Is the electrical isolation of 
each solar array section and the circuitry for limiting or regulating the 
solar array voltage. The primary power distribution equipment provides the 
tie points of the solar array and the batteries to the main bus. Included 
in the^primary power distribution equipment are power switches, protection 
devices, and power processing equipment required for the main bus opera- 
tion. Power output from the primary power distribution equipment is 
through load buses to either the power conditioning units or the loads. 

The power conditioning units convert the main bus voltage to the feeder 
voltages that are required by the loads. These units in general are high 
efficiency switching regulators, i.e., converters or inverters that provide 
dc-to-dc or dc-to-ac voltage conversion, respectively. Secondary power 
distribution hardware provides the distribution, switching, and protection 
for the power conditioning output voltages. The PMS is described below. 

6.3 FUNCTIONAL DESCRIPTION OF THE POWER MANAGEMENT SYSTEM 

The PMS monitors and controls the complete electrical power system 
from generation to load so that the monitoring, processing and decision, 
control, and recording functions can be efficiently and predictably per- 
formed. The PMS consists of I/O circuitry, power source controllers, load 
center controllers, electrical power subsystem controller, conmand and dis- 
play interfacing hardware, and the aala bus between the controllers. 

The PMS is a decentralized processing system from the standpoint \hat 
the power source controllers, load center controllers, and I/O circuitry 
are distributed throughout the spacecraft at various functional centers. 

An example of the distributed processing concept for an autonomously man- 
aged EPS is shown in Figure 6-2. In this example, the power system con- 
troller and <ts redundant backup controller are located in the spacecraft 
control center where power system Information is displayed for on-board 
personnel and is also available for further processing to the ground 
through the telemetry, tracking, and command (TT&C) subsystem. Power sys- 
tem commands are also received through the TT&C subsystem and are routed to 
the PMS controllers via the data bus. Power source controllers are located 
at power generation centers where solar array paver is Integrated with 
energy storage device power to form the main power buses for the space- 
craft. The main buses are then routed to tne various spacecraft load 
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Figure 6-2. Exanpte of Distributed Processing for an Autonomously 
Hanaged Electrical Power System 
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centers where the load center controllers are located. In the example, 
load centers for essential spacecraft loads have been distinguished from 
payload load centers. The payload load center controllers provide data 
processing for the payloads as well as the power system management. The 
thermal processing equipment Is also distributed throughout the functional 
centers, and ther.nal data Is processed by the respective distributed load 
center controllers. 

6.3.1 I/O Circuitry 

The I/O circuitry consists of sensors and signal processing circuitry. 
Monitoring functions are Implemented by the use of sensors. Sensors mea- 
sure various system parameters and generally transform these signals Into 
analogs that are usable by the electronic signal processing circuitry. The 
outputs from Che sensors are analog signals that are proportional to the 
Input parameters or the status of devices such as relay contacts. The 
analog sensors are transdicers that monitor voltage, current, pressure, or 
temperature. 

The sic'-.al processing circuitry gathers data from the sensors and 
processes thu data so that It can be used by the power source or load 
center controllers. The signal processing circuitry also processes com- 
mands from the controllers and routes them to the appropriate actuator. 
Specific functions of the signal processing circuitry are: multiplexing of 
sensor channels, analog-to-digital conversion, digital -to-analog conver- 
sion, encoding and decoding, and logic operations. 

6.3.2 Controllers 

Three types of microprocessor-based controllers are defined In the 
selected power management subsystem concept: electrical power subsystem 

controller (Figure 6-3), power source controller (Figure 6-4), and load 
center controller (Figure 6-5). The primary function of each controller Is 
to generate logical control decisions for the operation of the EPS and to 
manipulate sensor and other Input data. To accomplish this, logical pro- 
cessing and data storage functions are required. The microprocessor and 
memory elements of each controller Implement these functions. These ele- 
ments also provide for the Implementation of the algorithms that govern the 
control operations. The remaining major elements In each controller are 
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Fiyure 6-3. Electrical Power Subsystem Control lei Architecture 
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Input/output oriented and dependent upon the execution and Implementation 
requirements of the control functions assigned to each controller. 

Each controller may communicate with the other controllers over a 
common data bus. A bus Interface adapter (BIA) In each controller 
Interfaces this communication path as a two-way device. It formats the 
output data Into an appropriate message structure (rate, format, time slot) 
for convnunicatlon to other controllers; It also recognizes a proper Input 
message structure and decodes this message Into data/command format. The 
bus Interface adapter consists of four sections: bus Input/output cir- 

cuits, bus protocol logic, data buffers, and direct memory access Input/ 
output logK. The bus Input/output circuits Include line drivers and 
receivers, and encoders and decoders for the serial data stream of the data 
bus. The bus protocol logic performs serlal-to-parallel conversion and 
other low level functions of the high level data link; for example, special 
character decoding (message flag sequence and abort flag), zero bit 
stuffing and deletion, error checking, and Interrupt generation. The data 
buffers provide double buffering capability for the maximum length data 
frame. The direct memory access Input /output logic provides high speed 
data transfers between the bus Interface adapter data buffers and the 
microprocessor memory. 

Additional elements are Included In each controller to provide 
peripheral features such as power-on reset, timing checks to escape from a 
nondefinitive or excessively lengthy processing routine, and Interrupt 
procedures to prioritize processing routines. A digital Input/ output port 
Is provided on each controller for a serial data Interface to provide a 
human Interface to the system. Peripheral devices, such as printers and 
video/keyboard terminals, are connected to the system only during 
development, testing, and demonstration. 

The Electrical Power Subsystem Controller (Figure 6-3) Implements the 
management functions In the electrical power subsystem: for example, energy 
planning and allocation, load assignments, and command and data Interfacing 
to other spacecraft subsystems. These functions require communications 
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with other EPS controllers via the PMS data bus, and with other spacecraft 
subsystem controllers and the spacecraft computer via the spacecraft data 
bus. 

Included In the EPS controller Is a digital output port to drive a 
subsystem status display for human monitoring of the EPS status and opera- 
tion during system demonstration. Test and verification of flight hardware 
Is through the video/keyboard terminal Interface. 

The Power Source Controller (Figure 6-4) monitors the solar array and 
battery operation and controls the solar array output to provide the 
desired battery charging and load currents. Digital output ports are 
required to control switches to adjust the solar array outputs and to 
select the desired battery operating mode: charge/discharge, recondition 

discharge, discharge /disconnect shutdown for servicing. Digital and analog 
Input ports are required for the status and sensor data from the solar 
array and battery. The analog Input ports Include an analog-to-digital 
converter for the battery cell voltage, temperature, pressure, and current 
sensor data. This digitized data and the discrete status of the solar 
array switches are entered Into the controller memory for future reference 
In the command decision processing. 

The Load Center Controller (Figure 6-5) commands the load center 
switch-gear and monitors the results (both switchgear response and load 
parameters). Discrete commands control switchgear on/off operation, and 
parallel digital connands set the overload shutdown parameters of the 
switchgear. The switch gear status (on, off, tripped) and the actual load- 
bus current and voltage (analogs) are monitored. The data Is thereby 
available In the controller for determination of switch gear operation and 
(If required) definition of any corrective action required (new conmands). 

6.3.3 Command and Display 

The command and display circuitry provides the Interface with the per- 
sonnel for the monitoring and control of the power system during ground 
test or for application with a manned spacecraft. Power system conditions 
are displayed by means of status Indicators and Information Is provided 
through readout devices such as video displays. Commands are Issued 
through Input tenninals such as keyboards. 
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6.4 POWER MANAGEMENT SYSTEM DATA BUS 

The PMS data bus provides for bidirectional information transfer 
between the PMS controllers. The data bus uses a global architecture in 
that any single controller can communicate directly with any other con- 
troller on the data bus. The selection of the global architecture is based 
on the trade studies and analyses presented in Section 8.3. The global 
architecture works in conjunction with a distributed-control, time- 
sequential, data bus contention resolution scheme and the International 
Standards Organization (ISO) high-level data link control (HDLC) data bus 
protocol to provide the overall data communications design. Selection of 
the data bus contention resolution and the HOLC protocol is based on the 
trade studies and analysis presented in Sections 8.5 and 8.4, respectively. 
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7. HARDWARE DEVELOPMENT 

Hardware development for this phase of the program consisted of the 
development of two controllers: an electrical power subsystem (EPS) 
controller and a load center controller. Each controller consists of a 
microprocessor, memory. Input/output (I/O) circuitry, and a bus interface 
adapter (BIA). The microprocessor that was selected for the controllers is 
a Texas Instruments 9900 unit with 64K bytes of memory capacity. (See 
Section 6.6 for microprocessor selection tradeoffs.) Up to 20K of the 
memory car. be ROM with the remaining portion in RAM. The microprocessor, 
memory, and I/O circuitry were assembled from commercially available Texas 
Instruments printed circuit cards. The cards are assembled as a unit in a 
Texas Instruments TM 990/530 sixteen-slot card chassis. The BIA is being 
developed on a TRW internal research and development program (IRAD). The 
BIA will be fabricated on a universal prototype board, as shown in Figure 
7-1, which also fits into the card chassis. A picture of the overall 
system is shown in Figure 7-2. 

7.1 ELECTRICAL POWER SUBSYSTEM CONTROLLER DEVELOPMENT 

A block diagram of the EPS controller is shown in Figure 7-3. The 
controller consists of a BIA card (module), microcomputer card, and memory 
card. In addition, a floppy disk controller card is used as test equipment 
for development, test, and demonstration. The floppy disk was used to 
store the FORTH compiler and the power management system algorithms during 
this development phase of the project. A picture of the EPS controller is 
shown in Figure 7-4. Pictures of the microcomputer card and the memory 
card are shown in Figures 7-5 and 7-6, respectively. An interconnect 
diagram is shown in Figure 7-7. A detailed description of the printed 
circuit card can be found in Appendix B. 

7.2 LOAD CENTER CONTROLLER DEVELOPMENT 

A block diagram of the load center controller is shown in Figure 7-8. 
The controller consists of a BIA, microcomputer, memory, digital I/O, analog 
input, and DC I/O cards. A floppy disk controller card is also included in 
the load center controller dS test equipment for development, test, and 
demonstration. The load center controller is shown in Figure 7-9, 
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Figure 7-1. Universal Prototype Board (7.5 x 11 inch card) 
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Figure 7-2. Power Management System Controllers 
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Figurr* 7-5. Microcomputer Card (7.5 x 11 inch card) 
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Figure 7-6. Memory Card (7.5 x 11 inch card) 
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Figure 7-8. Load Center Controller Block Diagram 
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Figure 7-9. Load Center Controller ^19 inch rack mounting) 
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The microcomputer and memory cards are the same as those in the EPS 
controller and are shown in Figures 7-5 and 7-6, respectively. The digital 
1/U, analog input, and floppy disK controller cards are shown in Figures 
7-10, 7-11, and 7-12, respectively. An interconect diagram is shown in 
Figure 7-13. A detailed description of the printed circuit cards is 
contained in Appendix B. 
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Digital Input/Output Card {7.5 x 11 inch card) 
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Figure 7-12. Floppy Disk Controller Card (7.5 x 11 inch card) 
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Figure 7-13. Load Center Controller Interconnect Diagram 
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8. TRADE STUDIES AND ANALYSES 

Trade studies and analyses were performed in order to derive the 
appropriate power management subsystem (PMS) design. These trade studies 
and analyses are reported in this section. 

8.1 COST SAVINGS FROM AUTONOMOUS MANAGEMENT 

Analyses were performed to define the electrical power subsystem (EPS) 
cost savings that can be derived from autonomous management of the power 
subsystem. These cost analyses indicate that significant savings can 
result with autonomous management from reduction in ground support cost, 
from battery depth of discharge control (which enhances battery life), and 
from minimizing the operating time of the thermal coolant pumps (which 
lengthens pump replacement intervals) during reduced power periods. 

8.1.1 Ground Station Cost Reduction 

An analysis of ground station costs was performed to determine the 
potential for cost savings from incorporation of autonomous management of 
the power system. Ground station costs include the initial installation of 
the station, recurring maintenance and equipment refurbishment, and the 
support personnel to operate the station and verify satellite power system 
operation. A ground station similar to the Apollo tracking station at 
Goldstone is considered representative for the 250-kilowatt satellite. 
Projected cost of this station is $20M to install in 1980 (Reference 8-1). 
Refurbishing and equipment maintenance costs are typically 5 percent per 
year ($1M). The manpower to operate and maintain this ground station for 
the satellite power system is projected at 12 people and $910K per year, as 
summarized in Table 8-1. 

Satellite-to-ground telemetry requirements can be reduced greatly if 
the power system management is autonomous (on-board) and only data for out- 
of-tolerance performance and equipment degradation projections are trans- 
mi ttOred to the ground. The telemetry data is thereby reduced to that for 
satellite resupply and refurbishment planning functions. Thus, a separate, 
satellite-dedicated, telemetry-and-control station is not required. Exist- 
ing communication networks, such as the Tracking and Data Relay Satellite 
System (TDRSS), can be utilized on a time-share basis. This mode of 
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Table 9-1. Ground Station Personnel Annual Cost 


Function 

People 

Burdened 

Salary 

Total 

Cost 

Flight operators 

2 

$ 85K 

$170K 

Analysts 

6 

85K 

510K 

Technical Manager 

1 

lOCK 

lOOK 

Programmer 

1 

60K 

60K 

Secretary/Administrative 

1 

35K 

35K 

Clerical 

1 

35K 

35K 

Annual Personnel Cost 

$910K 


operation is projected as a one-man level of effort with time-share rental 
fees for conmuni cations. The annual cost is estimated at $100K. 

The projected costs of these power system management approaches 
(ground station control and autonomous on-board control) are compared over 
a 30-year period (Figure 8-1). The aggregate cost for ground station con- 
trol includes $2M for satellite telemetry transmission equipment (high data 
rate). The aggregate costs for autonomous management include $2M for the 
satellite on-board data processors. A substantial cost savings, approxi- 
mately $74M over 30 years (Figure 8-1), is indicated with autonomous power 
management. 

8.1.2 Battery Life Cycle Cost Reduction 

Battery cost savings are obtained when utilizing a PMS over the life 
of the satellite. This analysis shows how the PMS can save on battery cost 
by increasing the mean life of the batteries. Potential savings are beyond 
$5M on the nickel -hydrogen battery system for the 250 kWe space platform 
with 30-year mission life. First, a formulation of present expected cycle 
life of a battery for various depths of discharge (DOD) is developed from 
the empirical data (Figure 8-2) obtained from ongoing tests. A straight 
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Figure 8-1. PMS Reduces Monitoring and Control Costs 
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line approximation on the semi log graph of Figure 8-2 for 1986 gives the 
following relationship with x » DOD. 

Cycle life - L - 

From Figure 8-2: b » log 120,000 « 5.079 

a « log 120,000 - log 3,400 - 1.548 
L . jq 5. 079-1. 548x 

The cost of the batteries is given by the following relationship over a 
30-year life of the power system: 

Life cycle cost » ITTe" * ^i 


original 

op POOR 


where 

« replacement cost of batteries 
■ initial cost of batteries 
Lifej^ ■ mean life of batteries 

The batte'^y life cost is minimized by maximizing the mean life. A two- 
battery system, shown in Figure 8-3, is used to evaluate operation of a 
multi -battery system with balanced or unbalanced depth of discharge to 
maximize the mean life of the batteries. 


ISOLATION 



Figure 8-3. Two-Battery System 
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For the two-battery system shown in Figure 8-3, the following Is true 

®^total °°°des1gn " ^oad^esign* capacity 

BCj + BC2 - 

OOOj X BC^ + DODg X BC 2 ■ load (Ah) 
and 

BCj » BC 2 by design. 

OODj DOD 2 ■« load/BCj - K where K <2 

since the battery capacity Is always greater than the load. This equation 
gives DOD 2 as a linear function of DOD^, 

OOD2 - K - DODj 

The total cost for the two-battery system over 30 years Is given by: 



where and L, are the lives of the respective batteries. 

It ther follow* that the mean life Is determined as follows: 



To minimize the life rost, the mean life must be maximized; therefore the 
derivative of the mean life is taken with respect to DOD^ - x^ and set 
equal to zero. 
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Solving this equation, It follows that ■ K/2 gives maximum mean life. 

The details of this derivation are shown In Appendix E. 

To Illustrate the potential battery replacement cost increase for 
unbalanced depth of discharge operation, a graph of the Increased life cost 
of the batteries versus the degree of unbalance assuming a 250-1(1 lowatt 
load and a ITS-kllowatt load Is given by Figure 8-4. The depth of dis- 
charge unbalanced ratio Is given by assuming that half of the batteries are 
operating at 000^, and the other half at DOD 2 where 


DODj + DOD2 


DOD 


load 


which Is the required depth of discharge of the total battery capacity to 
meet the load specified. The points plotted are tabulated below: 


Load 

(kW) 

000. 

(%)^ 

000, 

(t)^ 

000^/0002 

Increased 

Cost 

(M$) 

250 

34.0 

34.0 

1.00 

0 

250 

30.2 

37.8 

0.80 

2.8 

250 

24.0 

44.0 

0.55 

9.0 

250 

19.4 

48.6 

0.40 

18.5 

250 

14.0 

54.0 

0.26 

31.7 

175 

24.0 

24.0 

1.00 

0 

\75 

18.0 

30.0 

0.60 

0.7 

175 

14.0 

34.0 

0.41 

2.8 

175 

8.0 

40.0 

0.20 

11.7 


A straight line approximation on a semi log plot for the cycle life of a 
battery Is thougl.t of as a conservative estimate by battery experts for low 
depth of discharge. It Is felt that with a cycle life for a very low depth 
of discharge, a much greater battery life will be realized than that pro- 
jected herein. To Illustrate how this Increased life expectancy might 
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Figurfe -l-A. Battery Load Balancing Reduces Cost 
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affect the previous derivation, another approximation of the cycle life 
versus depth of discharge relationship Is used which gives Infinite life at 
zero percent depth of discharge. That Is, 


L 



0 < X a 


Using this relationship. It can bo shown that the maximum of the battery 
mean life for a two-battery system Is still obtained by having a balanced 
depth of discharge, that Is ■ *2 “ 

If the cycle life has an extreme nonlinearity near a depth of dis- 
charge required to meet that load demand for balanced operation, it Is 
possible that a moi e optimal distribution of battery usage may be found. 
This might be the case for a lightly loaded system when the cycle life 
versus depth of discharge plot appears as shown In Figure 8-5. 



Figure 8-5. Llfe/OOD Relationship Cycle of a Battery with 
Extreme Nonlinearity Near Balanced DOD 


To Illustrate this, the two-battery system will again be used. The 
mean life for balanced operation is simply the cycle life of a single bat 
tery since ■ L 2 • Llfe^^: 


L1fe„ - 




L 


2 


Then letting Lg ■ mean cycle life of the batteries for the depth of dis 
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charge which gives balanced operation, the following relationships are used 
to represent the nonlinearity In the cycle life curve: 


L 


1 




1 £ Kj, K, 


and give Lj and L 2 respectively with + X 2 * K and and K 2 are 
undefined functions of x^. Then, the ratio of the mean life for unbalanced 
(Lub) operation to balanced operation (Lg) gives “he life ratio: 



Lg Lg 1 + KjK 2 


For the limiting case where • 1 and , the life ratio approaches 2. 

For this case where * Lg for Increasing 000, as Is Illustrated In Figure 
8-5, OOO 2 Is reduced to a point where L 2 Is Infinite. (Note: Battery 1 

and Battery 2 have Identical cycle llfe/OOO relationships.) As a result 
twice the mean life of balanced operation is obtained for this unbalanced 
case. This Is equivalent to having B^ solely supply the load and letting 
B^ rest where B^ has the same cycle life expectation whether solely supply- 
ing the load or equally sharing it with B 2 * It can be further shown that 
for an N battery system the limit ratio is N. These limiting cases are 
nonreal Izable since 1 for increasing 000^, but potential savings exist 
If < 2 and <2 > 1/2 (1 + K^K 2 ) for the two-battery system. A similar 
relationship can be derived for an N battery system. 

In conclusion, we see that the battery system should be operated with 
balanced DODs to substantially reduce cost. However, potential savings may 
also be obtained In battery costs If some distinct nonl Inearl ties exist In 
the cycle Ilfe/DOD relationship by operating the battery system with a more 
optimal distribution of depth of discharge. 

8.1.3 Thermal Coolant Pump Life Cycle Cost Reduction 

The power management subsystem can also reduce life cycle costs by 
extending the Interval between replacement of thermal coolant pumps. This 
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is accomplished by shutdowns of some pumps during periods of reduced elec- 
trical loads. For example, consider the payload power utilization of Fig- 
ure 8-6. During periods of reduced electrical load, the thermal cooling 
requirements are directly reduced, coolant flow can be managed accordingly 
(rather than relying wholly on bypass valves), and some pumps can be shut 
down : 

20 pumps are used for 250 kilowatts, 25 percent of the time; 

16 pumps are used for 200 kilowatts, 50 percent of the time; 

12 pumps are used for 150 kilowatts, 25 percent of the time. 

The average is only 16 pumps in operation and reduces the pump replacement 

costs by 5.3M$: 


20 pumps X 100K$/pump x 

16 pumps X 100K$/pump x 21.0M$ 

Potential cost savings 5.3M$ 

The degree to which this potential cost savings can be realized is depen- 
dent upon the judicious layout and organization of the coolant plumbing 
consistent with the payload operating scenarios. The resultant complexity 
of the coolant circuits must be consistent with the possible cost reduction 
in coolant pump life cycle costs. For example, several small pumps per 
coolant loop may be more cost effective than one large pump, 

8.2 POWER MANAGEMENT SYSTEM CONTROL HIERARCHY 

Tradeoff studies were performed to determine the control hierarchy for 
the power management subsystem (PMS) within the electrical power system. 
Centralized, distributed, and several hybrid concepts were considervfd 
(Table 8-2). The three-tier hybrid concept (Figure 8-7) was selected as 
the recommended hierarchy. This selection requires modest computational 
power in each controller, provides a well defined interface with the space- 
craft computer and other subsystems, provides subsystem autonomy for assem- 
bly, testing, and algorithm development, minimizes the quantity and dis- 
tance of sensor data transfer, incorporates subsystem control to simplify 
controller interactions and communications, and accommodates growth in both 
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EPSC • ELECTRICAL POWER SUBSYSTEM CONTROLLER 
PSC - POWER SOURCE CONTROLLER 
LCC - LOAD CENTER CONTROLLER 


Figure 8-7. Recommended PMS Architecture (Spacecraft, 
Subsystem, and Module Controllers) 
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energy storage (number of channels) and load center quantity. In addition, 
the algorithms, control routines, and controller hardware developed for 
this control hierarchy are applicable to the alternate approaches of Table 

8 - 2 . 

The recommended approach (Figure 8-7) employs three controller types: 
power source controller (PSC), load center controller (LCC), and electrical 
power subsystem controller (EPSC). This division of the control hierarchy 
is based upon the inherent separation of perfomance functions and their 
related spacecraft geographic locations. Sensor data transfer beyond the 
geographically separated local controllers is essentially eliminated. Com- 
munication between controllers occurs w th derived data rather than sensor 
data. The control ler-to-controller comiiiuni cation (data bus) traffic is 
thereby minimized and simplified. Further this natural division of control 
functions enables easy growth of the PMS with electrical power level growth 
by the addition of a power source controller with each additional battery/ 
channel and by the addition of a load center controller with each addi- 
tional load center. 

Alternate 1 configuration (Figure 8-8) omits the spacecraft computer. 
The spacecraft computer functions are distributed as appropriate into the 
controllers of the various spacecraft subsystems. This approach has essen- 
tially all of the performance attributes of the recommended option (Figure 
8-7). However, a significant degree of complexity is added to the subsys- 
tem controller interface software in order to communicate among subsystem 
controllers over the spacecraft data bus without a centralized controller. 

Alternate 2 configuration (Figure 8-9) retains the spacecraft com- 
puter, but eliminates the subsystem level controller. The functions of the 
subsystem level controller are transferred to the spacecraft computer. 

This approach retains most of the attributes of the recommended option 
(Figure 8-7) except for independent subsystem testing and subsystem control 
algorithm implementation. With subsystem control functions performed by 
the spacecraft computer, a more complex human interface is required to 
develop, code, and Implement these subsystem control algorithms. This will 
increase software costs. Also, the spacecraft computer (or equivalent 
subsystem support equipmenv - an additional cost) is required for subsystem 
level integration testing. In addition, the data bus interface for the 
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SPACECRAFT CONTROL 


GROUND STATION 



ADVANTAGES 

• EASIER TO IMPLEMENT REDUNDANCY 

DISADVANTAGES 

• POWER SYSTEM IS NOT SELF 
CONTAINED 

• HIGH SPEED BUS INTERFACE 

• EXPANSION LIMITED BY S/C 
COMPUTER CAPABILITY 


Figure 8-9. Alternate 2 PMS Architecture (Subsystem 
and Module Controllers) 
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module level controllers will be more complex due to the higher data rates 
required at the spacecraft level compared to the data rate at the elec- 
trical power subsystem level of the recommended approach. 

The subsystem-distributed architecture (Figure 8-10) employs only 
module level controllers. Consequently executive control functions must be 
distributed into these module level controllers. The resulting software to 
control communications on the data bus is very complex because executive 
control passes from controller to controller at this module level. This 
software complexity Is expected to increase software costs in excess of any 
hardware savings in avoiding the subsystem level controller or spacecraft 
computer. 

Three approaches avoid module level controllers: centralized space- 
craft control (Figure 8-11), spacecraft and subsystem controller architec- 
ture (Figure 8-12), and distributed subsystem controller architecture (Fig- 
ure 8-13). Two of these require a large electrical subsystem computer 
capability (Table 8-3), and the third requires a very large computer for 
spacecraft centralized control (Figure 8-11). However, each sensor geo- 
graphic area is serviced by “dumb** data bus Interface adapters. Hence, 
little cost savings are realized In hardware with these approaches. In 
addition, a high data rate communication bus Is required to transmit this 
sensor dota to the centralized processing locations. Also, growth is 
limited by the initially installed computational and memory capacities. 
Therefore, these approaches are rejected in favor of local (module level) 
processing options. 

8.3 DATA NETWORK ARCHITECTURE 

A global bus architecture was selected as the data bus concept fo.' the 
power management system because of its flexibility, reliability, failure 
tolerance, data rate accommodation, and equipment economy. This archi- 
tecture uses a single twisted pair electrical path (or single optical path) 
as shown In Figure 8-14 to minimize wiring between controllers. In this 
scheme, any single controller can communicate directly with any other 
controller on the data bus. Broadcast messages to all controllers can also 
be transmitted. The architecture works In conjunction with a distributed- 
control led, time sequential data bus contention resolution scheme 
(described in Section 8.5) and the International Standards Organization 
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Figure 8-10. Subsystem Distributed Architecture 
(Distributed Module Controllers) 
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Figure 8-11. Centralized Spacecraft Control Architecture 
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ELECTRICAL POWER SUBSYSTEM 



BIA - BUS INTERFACE ADAPTER 

Figure 8-12. Spacecraft and Subsystem Controller Architecture 
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Figure 8-13. Distributed Subsystem Controller Architecture 
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Table 8-3. High Speed Computer Required for Centralized Approach 


Functions 

1 

Repeat 

Time 

(sec) 

Number of 
Instructions 

Power Source (17) 



t Battery State-of-Health 

20 

83,100 

• Battery Charge Control 

2 

7,100 

• Solar Array Status 

20 

3,500 

Load Center (10) 


1 

• Switch and Load Monitoring 
and Fault In .errogatlon 

2 

17,000 

• Load On/Off Command 
Processing 

2 

2,600 

Power Subsystem 



• Spacecraft and Executive 

1 

8,700 

e Power Sub:ystem State 
o< Health 

60 

103,000 

• Energy Planning and 
Allocation 

300 

8,000 

• Load Assignments 

300 

5,400,000 

Total Instruction Rate 




Rate: 

Instructions 


85.000 

13.000 


8.700 

1.700 


18,000 


260,000 


Indicated Computer Speed Required for Centralized Computation : 
Instructions x 30% x 100% x Clock Cycles ■ Clock C 


Instructions 
per Second 


30% X 100% X Clock Cycles ■ Clock Cycles 
Overhead Margin per Instruction per Second 


260,000 


7 MHz 
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(EXPANSION) 

ADVANTAGES 

• MINIMIZES SINGLE POINT FAILURES 

• easily expanded 

• COMMON INTERFACE UNIT 

• FAILURE TOLERANCE 

• DATA RATE RANGE 

• ELEaRICALOR OPTICAL BUS 

• FLEXIBLE. RELIABLE. ECONOMICAL 

Figure 8-14. Global Data Bus Architecture 
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(ISO) high-level data link control (HDLC) data bus protocol (described in 
Paragraph 8.4) to provide the overall data communications design. 

The global architecture is inherently flexible. Growth of the data 
bus system and/or modification of the system topology is easily accom- 
plished by simple addition (or deletion) of the related BIAs and the asso- 
ciated data bus length without disturbing existing (or other) BIAs and data 
bus routing. 

The global architecture approach, incorporating the contention resolu- 
tion scheme and the frame checking sequence of the ISO HDLC protocol, is 
tolerant to many equipment (BIA) failures. Potential shorting of the data 
bus is minimized by transformer coupling between the BIA electronic compo- 
nents and the data bus lines. (This transformer is a critical element, 
though passive, and must be designed, manufactured, and tested to preclude 
failure). Failure of a BIA to transmit is tolerated by accommodation in 
the contention resolution scheme. Transmission of a garbled or unintel- 
ligible message may occur, but the message is negated at the receivers by 
the frame checking sequence validation routine of the ISO HDLC protocol. 

The following potential failure modes in a BIA affect the data bus 
operation: 

a) Failure to terminate transnission 

b) Transmission at the wrong time 

c) Transmission with a wrong but validated (by the frame check 
sequence, FCS) transmitter address. 

Assuring termination of transmission requires hardware redundancy in the 
BIA to preclude a single point failure. Transmission with a wrong but 
validated (by FCS) transmitter address causes some BIAs to be skipped in 
the contention resolution. Transmission by a BIA out of turn (at the wrong 
time) will garble the message from another BIA. Software and/or hardware 
protection for both these failures may be provided in the BIA design to 
avoid single point failures leading to these results. Alternatively, and/ 
or in addition, the EPS controller (or other authority) may monitor the 
data bus for these failure signatures (skipped BIAs in the contention 
sequence, and/or repetitively garbled messages), and the offending BIA 
placed in the IDLE or RECEIVE modes until repaired or replaced. 
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Typical data bus bit rates are 250 kilohertz, 1 megahertz, 

10 megahertz, and 40 megahertz. The lower rate (250 kilohertz) is suitable 
for a small power management subsystem comprising a few controllers. A 
1-megahertz data rate is appropriate for the 250-kilowatt electrical power 
system comprising 17 power source controllers, 10 load center controllers, 
and redundant (two) elect»'ical power system controllers. Larger power 
management subsystems or data bus commonality with other subsystems would 
require the higher data rates (10 to 40 megahertz). The global data bus 
architecture accommodates this great range of data rates. Typically, the 
250 kHz to 10 MHz data rates are suitable with either an electrical wire 
(twisted pair) or optical data bus implementation. Higher rates, typically ^ 

40 MHz, are provided by an optical data bus path. The basic BIA design for 
the global data bus is compatible with each of these data rates or data bus 
types. The BIA bus transceiver element is modified for electrical or opti- 
cal bus transmission, and the clock rate is adjusted accordingly. The data 
buffer in the BIA between the bus protocol control logic and the processor 
input/ output logic reconciles the differing data processing and transfer 
rates of the controller processor and the data bus. 

Other data transfer architectures considered were: 

a) Ring or loop bus. Figure 8-15 

b) Central switch control bus. Figure 8-16 

c) Central memory bus. Figure 8-17 

d) Complete interconnection. Figure 8-18. 

Each of these concepts has a major deficiency compared to the selected 
global data bus architecture. The central switch (Figure 8-16) and central 
memory (Figure 8-17) architectures each have major single point failure 
modes in the centralized switching and memory elements. The complete 
interconnection architecture approach (Figure 8-18) is inflexible for 
application to a utility power system expecting significant growth and 
reconfiguration. Redesign of all the BIAs is required at each expansion, 
or major initial overdesign of each BIA is required. The ring or loop bus 
architecture (Figure 8-15) places each BIA in series with the transmitted 
data. This results in a simple contention resol 'jti on scheme. However, 
each BIA must receive and retransmit the message even if not addressed to 
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Figure 8-15. Ring or 


ADVANTAGES 

• BUS INTERFACE UNIT (BIA) MODULARITY 

• SYNCHRONIZATION SIMPLICITY 

• CONTENTION ARBITRATION SIMPLE 

• EXPANDABLE SYSTEM 

DISADVANTAGES 

• MANY FAILURE POINTS (EACH BIA) 

• PROPAGATION DELAY IN EACH BIA 

Loop Bus Architecture 



0(pans7on) 


ADVANTAGES 

• COMMON INTERFACE UNIT 

• EASY 0(PANSION 

• SIMULTANEOUS MULTIPLE MESSAGES 

DISADVANTAGES 

• SINGLE POINT FAILURE (CENTRAL SWITCH) 


Figure 3-lb. Central Switch Control Bus Architecture 
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ADVANTAGES 

COMA^N INTERFACE UNIT 
EASY BIA ADDITION 

DISADVANTAGES 

SINGH POINT FA I HIRE MODE (CENTRAL MEMORY) 
MEMORY CAPACITY LIMITS EXPANSION 
HIGH MEMORY PROCESSING RATE REQUIRED 


Figure 8-17. Central Memory Bus Architecture 

ADVANTAGES 

• AVOIDS SINGLE POINT SYSTEM FAILURES 

• RECONFIGURATION CAPABILTIY 

• SIMULTANEOUS MULTIPLE MESSAGES 

DISADVANTAGES 

• EXPANSION/GROWTH AFFEaS EXISTING UNITS 

• EXTENSIVE Wiring for large quantity of units 

Figure 8-18. Complete Interconnection Architecture 
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that BIA. This imposes a major reliability impact with multiple BIAs in 
Sfcfies to transmit signals along the data bus. Any receive^ or transmitter 
failure of any BIA severely cripples or incapacitates the total data bus 
and thus system operation. 

8.4 DATA BUS PROTOCOL SELECTION 

A data-communi cation protocol is a set of criteria that first estab- 
lishes and then terminates a connection between processors; identifies the 
sending and receiving units; accommodates text, programs, control charac- 
ters, and differentiates among them; and verifies message integrity. A 
tradeoff analysis was performed to determine the appropriate data bus 
concept for the electrical power subsystem application. The criteria that 
were used to select the data bus concept are listed in Table 8-4. The 
first six criteria are related to cost-effective design practice for a 
distributed processing digital system. The last two criteria are appli- 
cable to the design of distributed processing spacecraft systems for power 
management and electrical system integration. 

Table 8-4. Command and Data Bus Selection Criteria 


• Minimum number of signal conductors (or optical fibers) 

• Simple hardware implementation (LSI is very desirable) 

• Minimum software intervention required to accomplish information 
transfer 

• Data block transfer capability 

• Reliable information transfer (error checking capability and simple 
methods for specifying retransmission of information) 

• Widely known and used (desirable for implementing as a standard) 

• High bit rate (up to 10 Mb/sec) 

• Space qualified hardware (and radiation hardened) 


Table 8-5 summarizes the characteristics of six data buses which were 
investigated. None of these buses satisfy all of the selection criteria; 
however, the bit-oriented protocols (HDLC, ADCCP, and SDLC) and the 
MIL-STD-1553B bus are the best candidates. Of these, the MIL-STD-1553B 
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bus was eliminated because of Its limited data block capability, complex 
software, and Inferior error checking capability. The bit-oriented proto- 
col buses are essentially the same except for some minor limitations in 
SDLC. The HDLC was selected because it is general purpose and is widely 
known and used. 

The structure of the HDLC message frame is shown in Figure 8-19 and 
consists of the start flag, address field, control field, information 
field, frame checking sequence field, and the end flag. The information 
field is further subdivided for this application into transmitter address, 
count, data type, and data fields as shown in Figure 8-20. 

The first set of bits to be generated in the format is the start flag 
field. The configuration of this flag byte is always 01111110, and this 
sequence will never be repeated again throughout the entire message 
transmission until the end flag with the same configuration is transmitted. 
In order to ensure this operation every time, when a sequence of five 1 
bits in a row is recognized by the transmit hardware after a start flag is 
generated (except when the end flag has to be generated), an extra 0 bit 
will be added to the bit stream between the fifth 1 bit and the next bit, 
regardless of whether that next bit is 0 or 1. This technique is called 
“zero stuffing." The hardware at the receive end will always remove a 0 
which is detected after five consecutive 1 bits before being passed on to 
the recognition logic and, therefore, will end up being transparent to the 
user (Reference 8-2). 

The Receiver Address Field is an 8-bit field that identifies the 
intended receivers of the message. This field provides 127 unique receiver 
addresses (2^ - 1) and a global address (all other receivers). This uti- 
lizes 7 of the 8 bits. The least significant bit (first bit sent) is used 
to indicate that either another address byte follows (a zero) or this is 
the final address byte (a one). Multiple, but specific, units may thereby 
be addressed with a common message. Alternately, the quantity of receivers 
may be increased beyond 127 by utilizing this address extension technique. 

The Control Field is a 16-bit field that typically contains command, 
response, or sequence numbers. The control field is used by the trans- 
mitters to identify special operations for the receiving bus interface 
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adapter. Presently, no special operations are Identified for electrical 
power subsystem management, and the field Is unused; the field contains 16 
zeros. 

The Information Field Is an even Integer multiple of 8-b1t groups 
(bytes) limited by the buffer storage and processing capacity of the bus 
adapters and processors. Typically, this limit Is of the order of 1000, 
2000, or 4000 bytes! (Two thousand Is provided In the electrical power 
subsystem bus adapter design.) This Information field Is subdivided Into 
transmitter address, count, data type, and data fields for application to 
electrical power subsystem control. 

The Transmitter Address field Is an 8-b1t field that Identifies the 
transmitter of each message frame. This address field provides 127 unique 
transmitter addresses (the same units as the 127 receiver addresses). The 
global address Is not used. The least significant bit (first bit sent) Is 
used to Indicate address field completion, I.e., a zero means more 8-b1t 
fields to follow, a 1 Indicates this Is the last 8-b1t address field. The 
quantity of transmitters may thereby be Increased beyond 127 by utilizing 
this extension technique. 

The Count Field is a 16-b1t field indicating the total length In bytes 
of the following two fields: data type and data. 

The Data Type fle’d Is a 16-b1t field Indicating the type of data in 
the message: command, equipment response, telemetry data,' equipment 

health, status monitor data, etc. 

The Data Field is an even Integer multiple of 8-b1t groups (bytes) 
limited by the buffer and processor capacity of the bus adapters and con- 
trol processors. This field contains the coded data message from the 
transmitter to the recelver(s). 

The Frame Checking Sequence (FCS) Is a 16-b1t field which Is an error 
checking code generated from the bits in the message frame, excluding the 
start and end flags and the FCS field (Reference 8-3). This ensures the 
received message can be judged to be error free In transmission and recep- 
tion, Erroneous data Is so noted, and software accommodates request(s) for 
retransmission. 


167 


34579-6001-UT-00 


A Flag F1g1d precedes and follows each message block. The flag 
sequence, serial "01111110," must be unique. Hence, the transmitting bus 
interface adapter inserts a zero bit in the transmitted data bus bit 
sequence after each fifth consecutive one bit of all other fields, includ- 
ing the frame checking sequence. Tlie receivers, in turn, automatically 
discard the zero after five contiguous one bits, thereby decoding the mes- 
sage block to the intended bit pattern. Six contiguous one bits thereby 
remain unique as the flag. 

A Clock Synchronization Field (clock sync) precedes and follows each 
frame. The clock is an 8-bit field of alternating zeros and ones; "01 01 
01 or (serial).* This provides a series of clocking pulses to allow the 
Manchester decoder in the receiver to synchronize with the transmitter 
encoder bit interval before data transmission conmences. The trailing 
field is required to maintain synchronization during the processing period 
(several uit times) following the end-of-message flag. 

8.5 OATA BUS CONTENTION RESOLUTION** 

At the conclusion of a message over the data bus, a contention problem 
exists to determine which data bus interface adapter (BIA) is allowed to 
transmit next over the data bus. A clear resolution of this contention for 
the data bus is mandatory, or two or more units (BIAs) may elect to trans- 
mit simultaneously resulting in garbled and unintelligible messages. The 
selected contention scheme was derived from several candidates and opera- 
tional options to assure communication capability even with some equipment 
failures. This contention scheme is designed to complement a global data 
bus architecture. 


Two-bit pattern representations are employed in digital engineering for 
parallel and serial bit display. Parallel display produces a mathematical 
bit pattern with the most significant digit to the left: 2^, ..., 2^, 2^, 
2^, 2^. This is the video (CRT) display of processor logic registers 
(parallel bit transfer). Serial display produces a bit pattern with the 
first bit sent written to the left, typically with the least significant 
digit first; 2^, 2^, 2*^, 2"^, ..., 2”. This is the oscilloscope display of 
serial data transfer. Discipline must be exercised to define which pattern 
a digital expression represents as two interpretations are possible without 
clarifying commentary (see Appendix D). 

The data bus contention resolution was developed on the TRW Internal 
Research and Development Program "Advanced Remote Integration Assembly," 
1981. 
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The contention for transmission on the data bus Is resolved by 
utilizing a distrlbuted-controlled, time-sequenti *1 access scheme. Each 
BIA Is allowed to transmit on the data bus In consecutive order; the order 
of transmission follows the same sequence as the ascending order of BIA 
addresses. When a BIA determines that it has access to the data bus. It 
must transmit at least one frame ; If there Is no information frame to be 
transmitted, the BIA will output a "token” frame, which Is addressed to all 
other BIAS on the bus (using the global, ^11 ones, address). A token 
frame, with preceding and succeeding CLOCK SYNC bytes, Is illustrated in 
Figure 8-21. 
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Figure 8-21. Token Frame 

I^ the controller processor has presented Its associated BIA with an 
information frame to be transmitted when access to the data bus is gained, 
this Information frame Is transmitted first. Each BIA is allowed to 
transmit only one information frame (a maximum of 2050 bytes) per bus 
access period. A token frame is then transmitted, with the closing flag of 
the information frame serving also as the opening flag of the token frame, 
as illustrated in Figure 8-22. 


INFORMATION 

FRAME 


TOKEN FRAME 


’Ih 


DATA 

h- tf— 


FCS 

FLAG 

RCVR 

AODR 

control 

XMTR 

AODR 

FCS 

FLAG 

CLOCK 

SYNC 












BYTE 

MARKS 




Figure 8-22. Message Frame and Token Frame 
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When a BIA receives a token frame, it will compare its address to the 
address of the BIA that sent the token frame (XMTR ADDR field). Each BIA 
which receives a token frame will then calculate the maximum number of BIAs 
which could gain bus access prior to its next access period; for conven- 
ience this number is called the access priority number. To allow tor the 
(reasonably probable) case where one or more BIAs with lower access 
priority numbers are not able (or on-line) to transmit token frames, each 
BIA will decrement its access priority number by one after a delay of 
14 byte times (112 bit intervals on the serial data bus) if no FLAG is 
observed on the data bus. This 14-byte delay time was derived from three 
components, two byte times to receive the CLOCK SYNC and FLAG fields, 

10 byte times to allow for the case when any BIA receives an erroneous 
frame, and two byte times for the maximum round-trip propagation delay of 
the data bus. Justification for a maximum one-way propagation delay of one 
byte time is given in Appendix F. If a FLAG is still not observed on the 
data bus after the first decrementing of the access priority number, each 
BIA will continue to decrement this number by one for every two byte times 
of delay, allowing only for additional maximum round trip propagation 
delays on the bus. Once a FLAG is observed on the data bus, each BIA will 
update its access priority number after receipt of the forthcoming token 
frame. If an erroneous frame (either information or token) is received, 
each BIA will delay for ten byte times and then decrement its access 
priority number by one. Once a BIA's access priority number reaches zero, 
it will have gained access to transmit on the data bus. 

When system power is turned on, all BIAs are reset to the IDLE mode. 
Under software control, the system controller BIA will enter the TRANSMIT- 
TOKEN mode, and start to Lend token frames. Other BIAs in the system will 
then be placed in the RECEIVE mode via software control. This power-up 
sequence will properly initialize the data bus contention resolution 
scheme. 

A second data bus contention scheme that was considered is carrier 
sense multiple access/collision detect. In this scheme, if the controller 
has data to send, it first listens to the data bus to see if any other unit 
is transmitting. If the data bus is busy, the controller waits until it 
becomes idle if the controller has data to send. When the controller 
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detects an idle data bus, it transmits a message. If, by chance, two 
controllers try to transmit simultaneously, a collision occurs. If a 
collision occurs, the controller waits a random amount of time anu starts 
over again (Reference 8-4). The carrier-sense, mul itpl e-access scheme 
provides the simplest hardware implementation but was rejected because of 
the complicated statistically based software required to respond to data 
bus collisions. 

The third data bus contention scheme that was considered is calle<d a 
"bit-map” method. In this scheme, a contention period is allotted to the 
data bus. The contention period contains one time slot for each controller 
on the data bus, as shown in Figure 8-23. If Station 0 has a message to 
send, it transmits a one bit during the first slot. No other controller is 
allowed to transmit during this slot. Regardless of what Station 0 does. 
Station 1 gets the opportunity to transmit a one during Slot 1 if it has a 
message to send. In general. Controller j may announce the fact that it 
has a message to send by inserting a 1 bit into Slot j. After N s’ots have 
passed by, each controller has complete knowledge of which controllers wish 
to transmit. At that point they begin transmitting in numerical order. 
Since everyone agrees who will go next, there will never be any collisions. 
After the last ready controller has transmitted his message, in event all 
controllers can easily monitor, another N bit contention period is begun 
(Reference 8-4). 

The bit-map method was rejected because it requires complicated hard- 
ware and a central clock for continuous synchronization; thus it is vul- 
nerable to single-point failures. 

8.6 MICROPROCESSOR SELECTION 

Commercially available microprocessor candidates were identified and 
evaluated for application as power source, load center, and electrical 
power subsystem controllers in a distributed power managetnent subsystem. 

The principal functions required of the microprocessor control ers are 
power switching decisions, command and data handling, and command decoding. 
Only moderate arithmetic processing capability is needed for battery charge 
control and system load balancing algorithms. Hence, there are many micro- 
processors (Table 8-6) that will meet the functional requirements for these 
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controller applications. Selection is therefore made on other factors 
which relate to a sound system design, such as: 

a) Availability 

b) Widely used, with good software and hardware design support 

c) Extensive family of input/output devices 

d) Capable architecture, with adequate speed and instruction set 

e) Space qualified, or radiation hardenable 

f) Compatible with Tektronix 8002A and Future Data development 
systems 

g) High level language capability 

h) Low (or moderate) power dissipation. 

Another system design goal is to provide enough flexibility so that 
upgrading to a more powerful microprocessor is possible without complete 
hardware and software redesign. This upgrade mobility permits an increase 
in processing capability as the application of microprocessor control 
expands with design experience and becomes more sophisticated. Thus, an 
important selection guideline is that the microprocessor be one of an 
evolving family of microprocessors with compatible input/output charac- 
teristics and upward compatible software (where possible). This permits a 
comparatively inexpensive step increase in system processing capability. 
This upgrade mobility is identified (Figure 8-24) for the various 
microprocessor candidates. 

Nine candidate microprocessors were identified and compared (Table 
8-6). The Texas Instruments SBP9900 microprocessor is the only one which 
satisfactorily meets all the selection criteria. The recent announcement 
of a new Texas Instruments microprocessor (available in 1981), called 
“Alpha", brings the 9900 family in line with the guideline related to 
future system enhancement by upgrading with a more capable microprocessor. 
The TI "Alpha" will have capabilities to make it competitive with the Z8000 
(Zilog, Mostek, AMD) and the MC68000 (Motorola), and its instruction set 
will be upward compatible with the 9900 and the 9989 microprocessors. 
Although the MC68000 and the Z8000 are perhaps the most powerful (16-bit) 
microprocessors on the market, they are NMOS devices (radiation soft). 
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Also, there are no CMOS versions of these two devices in the foreseeable 
future. Hence, the significant advantages o^ the TI SBP9900 outweigh the 
negative factor of the “unknown quantity" in the Alpha enhancement. 
Therefore, the TI SBP9900 is selected for the power management subsystem 
controllers primarily because a capable space-qualified device is available 
and presently available development systems can be utilized. 

8.7 SELECTION OF FORTH AS THE HIGH LEVEL LANGUAGE FOR 

DISTRIBUTED-PROCESSING ELECTRICAL POWER SYSTEMS 

The decision to use a high-level language to program the distributed- 
processing within the Electrical Power System was made primarily to reduce 
the cost and time required to develop software entirely in assembly 
language. Since high level languages are usually quicker to learn than 
assembly languages, less time should be required to develop applications 
programs. A second requirement was the selection of a language which 
facilitates structured design, which would allow the development of modular 
software. This property will decrease development time and increase the 
testability and maintainability of the system. 

Hardware limitations also restrict the selection of a high level 
language. Although the selected microprocessor (the SBP9900 from Texas 
Instruments) will support several high level languages, all except FORTH 
and TI's Power Basic would require the purchase of a development system. 

One of the strongest advantages of FORTH is its ability to be a complete 
stand-alone development system in less than 6K bytes of memory in the 
target system. Since Basic does not facilitate structured programming, 
FORTH is clearly the best choice from a hardware cost point of view. 

The requirement for a high level language which supports structured 
design, coupled with the strong desire for a language with fairly wide- 
spread usage, has restricted the choice to Ada, PL/M, Pascal, and FORTH. 
Since Ada compilers are not yet available, detailed investigations were 
limited to FORTH, PL/M, and Pascal. Each of these languages has its strong 
and weak features; i.e., no language is best for all applications. The 
evaluation and selection process should be tailored to fit the specific 
application, a real time spacecraft control system based upon functionally 
distributed processors. 
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FORTH has properties which fit the application remarkably well. A 
fundamental feature of FORTH is that the language and operating system 
reside in the same entity, a small set of constructs (called "words") which 
allow the user to build any new constructs, data structures, etc., that fit 
his particular application. Thus, FORTH has the property of extensibility 
(expandability and flexibility) which greatly facilitates incremental 
development of software in small steps. And FORTH explicitly contains the 
control constructs required for structured programming. 

The fact that FORTH provides the language, operating system, and 
stand-alone development system (in less than 6K bytes of memory) for each 
processing node is significant to the application. This feature will allow 
interactive dynamic testing of the distributed-processing system when 
multiple processors are actively operating in the system. This will be a 
very useful feature for test and evaluation of data bus protocols, and it 
will allow thorough interactive dynamic system testing to be a realizable 
goal at a reasonable cost. The current state-of-the-art test equipment for 
distributed-processing systems simply does not have comparable capability 
at a reasonable cost; a complete development system for each processing 
node in the system under test would be required to provide such capability. 

Execution time of code written in FORTH can approach 50 to 70 percent 
of the speed of assembly language code, and the FORTH code occupies less 
memory (60 to 80 percent of the equivalent assembly language code). Pro- 
grams written in Pascal or PL/M use approximately twice as much memory space 
as FORTH code, and execution times of Pascal or PL/M programs are signifi- 
cantly slower than programs written in FORTH. A report issued from General 
Electric Ground Systems Department has recommended the selection of FORTH as 
the standard language for all embedded processors in a distrubuted- 
processing image generation system (Reference 8-5). Table 8-7, which is a 
simplified version of a table in the report of Reference 8-5, shows the 
relative evaluation (on a scale of 1 to 10, where 10 is "best") of several 
factors involved in selecting high level languages. The author of the 

report claims that, "The data was secured from interviews with about two 

/ 

dozen expert programmers from business, scientific, and real-time 
backgrounds." 



Factors 

PASCAL 

FORTRAN 

BASIC 

PL/M 

COBOL 

FORTH 

1. 

Applicability for 
Large Programs 

10 

6 

3 

8 

7 

10 

2. 

Applicability for 
Small Programs 

8 

7 

10 

8 

3 

10 

3. 

Ease of Learning 

6 

8 

10 

7 

4 

6 

4. 

Supports Top-Down 
Design 

10 

5 

3 

7 

4 

10 

5. 

Control Constructs 
Supporting Structured 
Programming 

10 

4 

4 

10 

6 

10 

6. 

Writeabil ity of 
Large Programs 

10 

5 

3 

9 

5 

10 

7. 

Capable of Generating 
Efficient Code 

8 

7 

6 

10 

7 

10 

8. 

Flexibil ity of Data 
Types 

7 

5 

1 

6 

7 

10 

9. 

Capability of Com- 
piler to Check for 
Consistency and 
Errors 

10 

5 

4 

6 

7 

7 

10. 

Controlled Access 
to Data 

10 

6 

1 

3 

4 

10 

11. 

Language Supports 
Effective Problem 
Solving 

10 

6 

1 

8 

7 

10 

12. 

Readability of Large 
Programs 

10 

4 

2 

8 

8 

10 

13. 

Language Supports 
Transportabil ity 

7 

7 

4 

2 

9 

10 

14. 

Effectiveness of 
Standards 

3 

10 

4 

3 

10 

9 


Total s* 

119 

85 

56 

95 

88 

132 


Average Evaluation 

8.5 

6.1 

4.0 

6.8 

6.3 

9.4 


Each factor given an equal weight (»1). 
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The relative evaluations of compiler checking capability (Item 9, Table 
8-7), the capability of the language compiler to check for consistency and 
errors (In data operations, syntax, etc.), shows a significant weakness of 
FORTH, especially when compared to Pascal. Fur example, Pascal has (and 
Ada will have) the ability to locate Inconsistencies In manipulating data; 
Implicit mixed mode operations on data are prohibited. FORTH allows mixed 
mode operations, which causes some errors to be harder to detect. FORTH 
will also allow the definition of an array subscript which Is beyond the 
limits of the array definition. Another disadvantage of FORTH, when com- 
pared to Pascal or Ada, Is that FORTH tends to encourage an undisciplined 
programmer to use complex ”tricks“ Instead of simpler code which Is more 
easily read and understood. In order to help alleviate the disadvantages 
mentioned above, a set of programming rules and procedures will be defined 
before any FORTH programs are written. With the aid of an experienced 
FORTH programmer, a realistic discipline for FORTH programming will be 
established. 

Another commonly voiced “criticism" of the FORTH language Is that Its 
stack architecture and Its associated notation result in programs which are 
not easy to read. For passing parameters and returning results, the FORTH 
programmer uses a data stack, which he operates via reverse-Pol Ish-notation 
(RPN). 

Some users find RPN expressions difficult to read, but experience has 
shown that RPN is easily learned even by elementary students, not to men- 
tion the users of many calculators. Why a data stack and RPN Instead of 
the more traditional algebraic expression? A stack architecture offers 
several advantages (Reference 8-6): 

e Parameter passing between modules becomes implicit and 
extremely simple. 

t Problems associated with initialization and the validity range 
of variables In blocks disappear. Local variables, kept on the 
stack, need no names. 

• Variables are transparent to the user - a variable Is simply an 
address and the content of this address Is a value. The 
availability of addresses allows complex pointer calculations. 

• Module testing is very simple. The user explicitly puts 
parameters on the stack. In the interactive mode, to debug the 
module at hand. 


\ 
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• Words are executed in the order In which they are given to the 
system, making execution flow explicit. The programmer does 
not have to outguess the compiler. 

In summary, FORTH Is highly rated in twelve of the fourteen factors in 
the enclosed comparison table, and it rates highest overall of the six 
widely used high level languages. In additon, FORTH has decided advantages 
in execution speed, memory compactness, and significant advantages for 
system testing considerations, both economic and technical. It is clear 
that FORTH is the best a'^ailable high level language for the application. 
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9. CONCLUSIONS AND RECOMMENDATIONS 


A power management system concept has been presented for a 
250-kilowatt utility-type electrical power subsystem for a low-earth orbit, 
large-space platform. This concept utilizes a decentralized data proces- 
sing approach to achieve autonomous operation of the electrical power sub- 
system. The algorithms required to perform the power management functions 
were identified and algorithm development was initiated with the develop- 
ment of load bus assignment, command processing, and monitoring algorithms. 
The power management system hardware development was initiated with the 
assembly of an electrical power subsystem controller and a load center 
control ler. 

9.1 CONCLUSIONS 

The major conclusions concerning the power management system are as 
follows: 

a) The power management system concept (as presented herein with 
autonomous operation) is a cost effective approach from the 
standpoint that it reduces ground station operational costs, 
reduces shuttle resupply costs, and extends equipment life. 

b) An on-board power management system, as presented herein, will 
be required (enabling technology) for large space platforms due 
to increased data requirements imposed by system complexity and 
component interactions. This conclusion assunes that present 
telemetry channel constraints will continue to exist. The 
increased complexity of the electrical power subsystem will 
require computerized analysis of system anomalies and degraded 
components in order to provide corrective action within an 
acceptable time frame. 

c) Power management provides an alternate path to technology 
readiness of large space platform power subsystems, rather than 
having to develop large power subsystem components, by provid- 
ing the capability to operate more complex systems. 

9.2 TECHNOLOGY DEVELOPMENT RECOMMENDATIONS 

Technology developments for the power management system fall into two 
major categories: hardware development, and algorithm development. State- 

of-the-art developments in power management hardware are such that only one 
major development appears to be required. This is the development of light 
weight, low power, accurate sensors which include current and pressure 
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sensors. The large number of sensors required to control and understand 
the status of the electrical power subsystem Is the major driver towards 
this development. 

Other hardware developments, such as microprocessors, appear to be 
progressing rapidly due to data processing requirements In the commercial 
sector. Although only one radiation hardened microprocessor Is available 
at this time, several capable CMOS processors are coming on the market that 
appear adequate for the power management system applications. Data com- 
munications technology such as data bus protocols are being developed by 
the commercial sector for distributed processing applications In banks, 
airlines, etc., that appear to be more than adequate for the power manage- 
ment system application. 

The major technology development that Is required Is the development 
of the electrical power subsystem algorithms (operational strategies/ 
procedures). The autonomous operation requires preplanned decisions to be 
made and Implemented Into the on-board controllers. The utility-type 
operation requires a new approach to power management In that load profiles 
are unknown and rr.dundancy management Is required with degraded operation 
for full system utilization. Shuttle resupply requires new operational 
techniques In that degraded performance must be analyzed and predicted In 
order to minimize the number of shuttle resupply trips that are required. 


184 


34579-6001-UT-00 


10. REFERENCES 


5-1 Tomlinson 6. Rauscher, "A Unified Approach to Microcomputer software 
development" Computer , June 1978. 

8-1 Bob Stevens, Division Manager, Telecommunications Division of Jet 
Propulsion Laboratory, personal conversation. 

8-2 Kenneth Sherman, Data Communications, Reston Publishing, Co., 1981. 

8-3 ISO 3309, Paragraph 3.6, Frame Checking Sequence (FCS). 

8-4 Andrew S. Tanenbaum, Computer Networks , Prentice-Hall, 1981, p. 296f. 

8-5 R. Johnston, "Programming Language Study Report," General Electric 
Ground Systems Department, 4 June 1979. 

8-6 Michel Mannoni , "FORTH - an Extensible Path to Efficient Programs," 
Electronic Design Magazine, 19 July 1980. 


34579-6001-UT-00 


APPENDIX A 

LEIGHTON DIAGRAM SYMBOL DEFINITION 

The structijred design of an algorithm Is typically Illustrated by a 
Leighton diagram. The diagram Illustrates processes, decisions, sequence 
of events, and Interfaces. The sequence of events Is defined by reading 
the diagram from top to bottom and left to right. The symbols In the 
diagram are defined below: 


A box Indicates a process. 


A diamond Indicates a decision. 


An arrow Indicates that the processes are to be 
performed In sequence or In a loop. 


A parallelogram Indicates an input or output 
destination. 


A shaded box indicates that this process 1? for 
demonstration only, and would not be Included In a 
flight pregram. 
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APPENDIX B 

TI TM-990 MODULE DESCRITPIONS 


Engineering demonstration consoles were assembled for the Electrical 
Power Subsystem Controller (EPSC) and the Load Center Controller (LCC). 
These consoles utilize the Texas Instruments TM-990 series microcomputer 
modules for the microprocesssor , memory, interface (I/O) circui-.ry, and 
mounting hardware. The following sections provide a brief description of 
the functions and features of the selected hardware. For more complete 
detailed descriptions, refer to the TM 990 Microcomputer Catalog (handbook) 
by Texas Instruments. 

1. TM 990/101MA-3 MICROCOMPUTER CARD 

The TM 990/101MA-3 is a preassembed and tested microcomputer module 
(Figure B-1) which utilizes the 16-bit, NMOS, TMS 9900 microprocessor as 
its central processing unit. RAM and ROM/EPROM memory and programmable 
serial and parallel data inputs/outputs are included or. the card assembly. 
Major features are: 

• TMS 990U 16-bit CPU 

t 4K bytes of TMS 2114 static RAM 

t 2K bytes of ROM 

• 16 progranmable I/O lines 

• Two RS-232C serial ports 

• Fully expanda')’, jus structure and DMA to on-board memory 

• 3 MHz operation 

• Three programmable interval timers 

• Seventeen interrupts: 2 nonmaskable, and 15 prioritized and 

maskable 

■ Edge triggered interrrupt, with software reset 

• Cotimuni cations Register 'Jnit (CRU) addressable LEDs and DIP 
switches for custom applications 

• Designed to fit TM 990/530 card cage. 
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2. TM 990/201-42 MEMORY CARD 

The TM 990/201-42 is a prsassembled and tested meniory expansion board 
designed for use with the TMS-9900 based microcomputer modules such as the 
TM 990/101MA-3. The TM 990/201-42 is socketed for both static RAM and 
EPROM memory and is expandable to a maximum configuration of 16K bytes of 
RAM and 32K bytes of EPROM. Major features are: 

• Bus compatible with the TM 990/101MA-3 microcomputer card 

t 16K bytes of TMS 2716 EPROM installed; expandable to 32K bytes 

t 8K bytes of TMS 2114 static RAM installed; expandable to 16K 
bytes 

t Memory map is completely configured 

• 1 microsecond cycle time (3 MHz) 

• TTL-compatible interface 

0 Designed to fit the TM 990/530 card cage. 

3. TM 990/310 DIGITAL I/O CARD 

The TM 990/310 is a preassembled and tested input/output expansion 
card (Figure B-2). This card provides expansion of 48 I/O points that are 
programmable as either input or output. Major features are: 

0 Compatible with the TM 990 microcomputer module CRU bus 

0 Up to 27 I/O lines may be programmed as prioritized, unlatched 
interrupts 

0 Three (+) and three (-) edge-triggered and latched, prioritized 
interrupt inputs are provided (in addition to 48 I/O lines) 

0 Contains three real-time clocks (or event timers) 

0 I/O lines are provided with echo-back feature, 

0 Inputs/cutputs are TTL-compatible 

0 May be used with solder, wire wrap, or ribbon cable edge 
connectors 

0 Designed to fit the TM 990/530 card cage. 
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Figure B-2. TM 990/310 Block Diagram 
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4. TM 990/1240-R ANALOG I/O CARD 

The TM 990/1240-R is a preassembled and tested analog I/O card. This 
card converts analog input signals to a 12-bit digital form (Figure B-3). A 
multiplexer is included to intermix 16 single-ended analog signals for 
conversion. The data bus, control bus, and address bus connections to the 
interfacing microprocessor are included on the card cage connector wiring 
(TM 990/530). Major features are: 

• Memory mapped I/O interface 

• 12-bit resolution and accuracy 

• Single +5 volts power 

• 256 input channel expansion capability 

t Input overvoltage protection 

• Rjsistor programmable input gain 

• Interrupt operation capability 

• Designed to fit TM 990/530 card cage. 

5. TM 990/5MT43 DISCRETE INTERFACE MOUNTING BASE 

The TM990/5MT43 interface assembly is designed to handle ac and dc 
"input" functions. The interface assembly consists of the TM 990/5MT43 
mounting base and plug-in interface modules (Table B-1). Both the input 
and output modules are solid state and are optically isolated. Internal 
protection against harmful voltage transients and RFI noise is provided in 
the system to eliminate the need for external filters clippers, or sup- 
pressors. The mounting base will accommodate up to 16 modules. 

Major features are: 

t Designed for industrial applications 

• Individual plug-in modules 

f Prewired mounting base 

• Optical coupled isolation 

• One I/O point per module 
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• LED status indicator 

• Input and output modules 

• Compatible with TM 990 microcomputer system 

• AC, DC modules 

e 1500-volt isolation between input and output. 


Table B-1. Module Availability 


Catalog No. 

Type of Device 

Rating 

Voltage 

Current 

TM 990/5MT1A05L 

AC Input 

90-132 VAC 

35 mA Max 

TM 990/5MT1E05L 

AC Input 

17-28 VAC 

18 mA Max 

TM 990/5MT240AL 

AC Output 

90-132 VAC 

3 A Max 

TM 990/5MT240EL 

AC Output 

17-28 VAC 

3 A Max 

TM 990/5MT3D03L 

DC Input 

3-28 VDC 

30 mA Max 

TM 990/5MT430CL 

DC Output 



10-28 VDC 

1 A 


6. TM 990/303A FLOPPY DISK CONTROLLER CARD 

The TM 990/303A is a preassembled and tested control card designed to 
interface between the TM 990/101MA-3 microcomputer card and selected disk 
drives (Figure B-4). 

• Shuggart model SA 400 (mini) 

• Shuggart model SA 800 (standard) 

• Control data model CDC 9404B (standard) 

e Qume DT^' (standard double-sided). 

The TM 990/303A also provides DMA capability with the TM 990/101MA-3 
microcomputer board or with any expansion memory board (e.g., TM 
990/201-42). Major features are: 

t Formats supported (soft-sectored): 

IBM single density 

IBM double density 
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II single density FD800 (currently used on the FS 990/4 and 
AMPL systems 

Tl Digital Systems Group (DSG) double density format 

• Disk sizes: Standard or mini 

• Disk sides: Single or double (with Qume DT/8) 

• Number of disk drives (daisy chained): Four maximum standard 

size or three maximum for mini size 

• Recording methods: 

single density frequency modulation (FM) 

double density modified frequency modulation (MFM) 

• Data structure: 

TF FS 990 compatible 
IBM 3740 compatible 

• System interface: 

CRU (controller initialization) 

DMA transfer (data and commands) 

• Three LEDs indicate controller status 

• Bootstrap load features can be used to initialize system from 
di skette 

• Controller firmware provided on two TMS 2716s (2K words); con- 
troller firmware EPROM space expandable to 4K words by using 
two TMS 2532s 

• DMA data transfer 

t 20-bit host memory addressing 

• Read after write 

• Disk coimand chaining. 

Software on the controller includes the following features: 

• Seventeen commands including controller self test, read and 
write to/from diskette, read to and write from controller/RAM, 
bootstrap load from diskette software, format diskette, execute 
program in controller memory, and read status cf specified 
drive 


197 


34579-6001-UT-00 


• Command completion Interrupt to host (Interrupt level jumper 
selectable); completion status reported to host 

• Controller initialization through interrupt via CRU 
7. TM 990/530 CHASSIS 

The TM 990/530 is a preassembled chassis designed for 19-inch rack 
mounting (Figure B-5) that accommodates 16 cards and provides backplane 
interconnections for the address bus, data bus, interrupt, and control 
lines. The TM 99Q/530 chassis can accomodate the addition of cooling fans 
(Figure B-6) for forced-air cooling of chassis mounted cards. 
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APPENDIX C 

DEFINITIONS OF DIGITAL TERMS 

Connon digital engineering terms are used in tnis and subsequent 
reports on the progress of the controller and data bus hardware and 
software. These terms are herein defined as applied to this study: 

BIT - A binary digit ("0” or T) 

BLOCK ■ The field of contiguous bits between two synchronization 
bytes 

BYTE - A specific field of 8 contiguous bits. 

CHARACTER * A byte representing a teletype hieroglyphic; typically 

alphanumerical plus punctuation and selected common 
mathematical symbols. 

FLAG « The unique telltale byte "01111110" (serial); marks the 

start and end of frames. 

FRAME ■ Two flag bytes and the field of bits between them. 

MESSAGE ■ One or more frames; a lenghty message may require 

several frames for complete transmission. 

NIBBLE ■ A specific field of 4 bits; the first 4 bits or last 4 
bits of a byte (least significant nioble, most 
significant nibble). 

WORD = A specific field of two contiguous bytes (16 bits). 
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APPENDIX D 

HEXI-OECIMAL CHARACTER DEFINITIONS 


Hex 1 -Decimal 
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Notes: (1) Typical video display of processor logic 

registers (parallel data transfer). 

(2) Typical oscilloscope display of data bus bit 
transmission (serial data transfer). 
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APPENDIX E 

DERIVATION OF MINIMUM LIFE CYCLE COST 


To minimize the life cost of the batteries, the extrema of the life 
cost equation are found for varying depth of discharge (DOD). To minimize 
the life cost, the mean life must be at its maximum. The mean life of a 
two-battery system is given by 


L L 

• 2 It— rq 


b-ax. b-ax« 

where L^^ » 10 ^ and L 2 = 10 ^ , 


Since ^2 “ ^^^1 derivative of the mean life is taken 

with respect to DOO^ » and set equal to zero. 



LjI-2 




b-ax. 

10 ^ . 

b-ax. + 
10 ^ 


b-ax 

10 


b-ax, 

10 


= 0 



10 


2b-aK 


b-v'.x, + 

10 ^ 10 


b-a 




Note: 


d 

dx. 


/A . B \ '^^l 

7(rTT)“-- 


^ (A + B) AS - M (A + B} 


(A + B) 


r 


and 




b-ax. 



/ b-ax 
(lO 
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b-a(k-x) 

+ 10 ^ 


b-ax. 


* -alO 


(In 10) + alO 


b-ak+ax 
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= 0 


(In 10) » 0 
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♦ +b - ax^ ■ b - ak + axj^ 

♦ Xj ■ K/2 is the extrema point, that is x^ * x^ » K/2 

This is an extrema point, whether a maximum or minimum remains to be 
determined. For x^ » K/2 




, , 44 1 ,„b-aK/2 


M 


Letting x^ » K/2 + e where e ♦ 0 


UfeM 


2M 

10 ’^' + 10 ®* 


Now, is h* a minimum or a maximum? 


Ml . 

- 10 * + 10 ®* 


for e 0 


1 i * 1 > ^ 

- 10‘®* + 10®* lO’®* + 10®* 

since 10®* + 10"®* is always greater than 2 for e 0. Therefore, Life„ is 

n 

a maximum at “ *2 * K/2, Then it follows that by operating the bat- 
teries with a balanced depth of discharge, for any given load the life cost 
is minimized. 
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Apr END IX F 

DERIVATION OF MAXIMUM ONE-WAY BUS PROPAGATION DELAY 


Assumptions: 

Signal propagation velocities: 

Wi re — 0.15 m/ns 
Optical Fiber — 0.19 m/ns 

Maximum bus length: less than 120 meters 

Calculation of maximum bus propagation time: 

Wire ~ 120m f 0.15 m/ns » 800 ns 
Optical Fiber -- 120m i 0.19 m/ns » 632 ns 

At 1.0 Mb/s serial bus data rate, the maximum propagation delays in 
bit times are: 

Wire — 0.8 bit time 

Optical Fiber -- 0.632 bit time 

At 10.0 Mb/s serial bus data rate, the maximum propagation delayi are: 

Wire -- 8 bit times 

Optical Fiber — 6.32 bit times 

A 120-meter wire bus operating at 10.0 Mb/s was selected as the 
limiting case.* 

Worst-Case Maximum** Delay for any BIA to Wait for Bus Access 
(assuming 30 BIAS on bus ):~~ 

at 1.0 Mb/s serial bus data rate: 0.58644 second, 

at 10.0 Mb/s serial bus data rate: 0.058644 second. 

Maximum**Transmission Delay for bus Access With No Information Traffic 
(with 30 BIAS on bus) : 

at 1.0 Mb/s serial bus data rate: 2.55 milliseconds, 

at 10.0 Mb/s serial bus data rate; 255 microseconds. 

Figure F-1 illustrates the limitations of bus access time. 


Since the clocks of two BIAs could be a maximum of one bit-time relatively 
asynchronous, the maximum wire bus length should be limited to 100 meters. 

"Maximum” delay means that software transmit request just missed the bus 
access period. 
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Figure F-l. Data Bus Access Time 




